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1  Introduction 

This  report  describes  an  investigation  of  techniques  to  support  the  specification  and  verification  of 
concurrent  and  distributed  software  systems,  with  special  emphasis  on  issues  of  security.  The  inves¬ 
tigation  has  focused  on  two  major  areas.  The  primary  focus  is  a  survey  of  existing  methodologies 
and  systems  that  are  relevant  to  the  specification  and  verification  of  concurrency.  The  secondary 
focus  is  on  the  initial  design  of  a  short-term  workbench  that  embodies  capabilities  of  existing  sys¬ 
tems  together  with  new  features  that  extend  the  current  state  of  the  art  in  the  specification  and 
verification  of  concurrency. 

The  remainder  of  the  introduction  to  the  report  summarizes  our  survey  results  and  presents 
our  overall  conclusions  about  the  current  state  of  the  art.  Sections  2  and  3  of  the  report  present 
the  details  of  the  methodology  and  system  surveys  respectively.  The  surveys  include  high-level 
feature  comparison  tables  accompanied  by  extended  reviews.  Section  4  describes  our  design  for  the 
short-term  workbench  that  will  support  computer-aided  specification  and  verification.  Section  5 
describes  a  set  of  extended  examples  that  we  have  developed  to  test  our  design  ideas.  Section  6 
concludes  with  an  overall  summary  and  an  overview  of  targets  for  future  work. 

1.1  Summary  of  Survey  Results 

fn  the  initial  months  of  the  project,  we  reviewed  approximately  200  abstracts  of  papers  in  the 
following  topic  areas: 

•  Specification  languages,  for  both  sequential  and  concurrent  programs 

•  Program  verification  methodologies  and  systems,  for  both  sequential  and  concurrent  programs 

•  Programming  languages  for  concurrent  and  distributed  programming 

•  Software  environment  support  for  specification  and  verification 

From  the  200  abstracts,  we  selected  approximately  thirty  papers  for  detailed  review  and  critique. 
Those  papers  selected  for  detailed  review  included  work  from  the  most  visible  and  productive 
researchers  in  the  field,  as  well  as  other  representative  work.  IVom  the  members  of  the  project  team, 
we  selected  one  or  two  individuals  to  be  specialists  in  particular  areas.  The  specialists  thoroughly 
reviewed  each  of  the  papers  in  their  respective  areas  and  prepared  a  formal  presentation  on  the 
results  of  the  review  to  the  rest  of  the  project  group. 

In  conjunction  with  the  literature  review,  we  have  reviewed  approximately  two  dozen  systems 
that  have  features  to  support  computer-aided  specification  and/or  verification.  Of  these  we  have 
gained  actual  hands-on  experience  with  ten.  The  systems  selected  for  review  have  one  or  more  of 
the  following  features: 

•  support  for  a  formal  specification  langu^e  in  the  form  of  parsing,  type  checking,  and  possibly 
other  forms  of  language  analysis 

•  support  for  execution  of  formal  specifications 

•  support  for  computer-aided  verification 

•  software  engineering  support  for  specification  and  verification 

Based  on  the  results  of  the  survey,  we  have  compiled  two  "short  lists”  of  methodologies  and 
systems  that  we  believe  represent  the  fundamentally  important  concepts  necessary  for  the  tasks 
of  specification  and  verification  of  concurrency,  srith  special  emphasis  on  security  properties.  The 
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methodologies  end  systems  chosen  for  inclusion  in  the  short  lists  comprise  e  broedly  representative 
set,  covering  the  major  researchers  working  in  the  area. 

The  methodology  short  list  includes  of  the  work  of  eight  of  the  major  research  groups  in  the 
fields  of  specification  and  verification,  with  emphasis  on  concurrency.  The  methodologies  are  listed 
below  by  their  associated  authors  with  a  brief  synopsis  of  the  key  features: 

•  Barringer  and  Meams  -*  important  technical  concepts  for  the  specification  of  concurrency 

•  Chen  and  Eoare  -  foundations  for  specification  and  verification  of  concurrency  in  the  CSP 
language 

•  Chen  and  Yeh  •  fbundatioxu  for  event-based  specification  of  concnrrency 

e  Flon  and  Suxuki  •  important  work  on  specification  of  concorreaCy  via  transformation  to 
nan-concurrent  representations 

e  Ealpcm  and  Owicki  -  widdy  referenced  work  on  modular  specification  and  verification  of 
concurrency  based  on  computation  histories 

•  Jones  •  important  concepts  in  process-oriented  specification  of  concurrency 

•  Lamport  -  foundational  work  on  temporal  logic  and  other  basic  concepts  of  concnrrency 

•  Misra  and  Chandy  -  well-recognised  work  on  very  high-level  specification  of  concurrency 

The  system  short  list  consists  of  six  of  the  most  representative  tools  for  computer-aided 
specification  and  verification: 

e  Affirm  -  provides  basic  support  for  algebraic  specification 

•  £HDM  -  wide-range  of  support  for  specification  and  verification  including  software  engi¬ 
neering  support 

e  FASE  >  strong  support  for  executable  specification 

•  HOL  -  powerful  and  general  computer-aided  verification  system 

e  Larch  -  provides  basic  framework  for  two-tiered  approach  to  specification  adopted  in  the 
design  of  our  prototype  workbench 

s  OBJS  -  strong  support  for  execution  of  specifications  and  extendible  so  support  high-level 
specification  of  concnrrency 

Tlte  rationale  for  the  selection  of  both  of  these  short  lists  is  based  on  a  number  of  factors. 
These  factors  are: 

•  CempUienets  -  those  chosen  comprise  a  complete  and  representative  set,  with  no  major 
methodology  concepts  or  system  capabilities  not  covered  by  at  least  one  member  on  the  lists 

•  SmiaUKiy  for  iht  task  at  hand  •  the  systems  should  be  rdevnnt  or  potentially  rdevant  to  the 
specification  of  conenrtency  and  security 

e  Syttem  medifiMlUy  and  ttahiHiy  >  for  the  listed  systexxu,  the  source  code  for  the  systems 
must  be  public  and  readily  available  E  the  systems  are  to  be  modified  to  support  concurrency 
e  Familiarity  -  when  aU  other  factors  are  equal,  we  prefer  methodologies  and  systenu  of  which 
we  have  working  knowledge  and  axpaiiaact 

Based  on  these  factors,  we  believe  that  our  lists  include  a  representative  sample  of  method¬ 
ologies  and  systems  that  afford  us  full  coverage  on  the  state  of  current  research  and  development. 
The  lists  also  form  the  basis  for  the  ideas  that  wiU  be  embodied  in  the  design  of  the  short-term 
workbench. 
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1.2  Summary  of  Conclusions  and  Recommendations 

Rather  than  wait  until  the  end  of  a  lengthy  report  to  present  oor  overall  conclusions,  we 
snxninarue  them  here  based  on  the  introduction  presented  thns  far.  We  present  a  more  technically 
oriented  review  of  our  conclusions  in  the  final  section  of  the  report.  The  conclusions  are: 

•  Many  methodologies  exist  for  concurrent  specification  and  verification,  including  several  that 
focus  on  security. 

•  Many  systems  exist  that  support  specification  and  verification  for  sequential  programs. 

•  Very  few  systems  exist  that  support  eonatrreni  specification  and  verification,  and  certainly 
no  single  complete  system  exists. 

•  We  need  a  discriminated  union  of  the  difierent  features  in  the  methodologies  and  systems  on 
our  short  lists  in  order  to  provide  a  single  mmplete  system. 

•  Very  few  of  the  methodolopes  and/or  systexru  address  verification  of  both  specification  and 
code;  we  bcheve  that  code<level  verification  is  cmdal  for  the  honest  verification  of  security 
and  we  plan  to  address  this  issue  in  our  workbench  design. 

•  The  design  of  our  short*term  srorkbench  will  be  built  on  existing  ideas  and  systems,  not  from 
scratch;  this  includes  the  reuse  of  existing  code  from  one  or  more  of  the  systems. 

1.3  Summary  of  Novel  Research 

As  we  have  completed  the  surveys,  we  have  found  that  there  is  a  large  amount  of  novel  research 
to  be  done  in  the  areas  concurrent  specification  and  verification.  In  the  design  of  our  prototype 
workbench,  we  have  begun  some  of  this  research,  specifically  in  the  following  areas: 

•  The  algebraic  specification  and  verification  of  concurrency 

•  The  algebraic  specification  of  security  properties 

•  The  axiomatic  semantics  of  the  SR  concurrent  programming  language,  and  its  use  in  a 
methodology  that  will  verify  both  specification>level  as  weU  as  code-level  security  proper¬ 
ties 

e  A  model  for  a  Secure  Resource  Manager  that  will  provide  the  platform  for  high-level  specifi¬ 
cation  and  testing  of  security  properties 

•  The  specification  of  a  secure  network  mail  handler 

e  A  proposal  for  a  secure  distributed  operating  system  kernel 

Our  research  has  resulted  in  a  number  of  papers  submitted  for  publication  which  we  hope  to  see  in 
print  in  the  very  near  future. 
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2  Methodology  Survey 


This  section  of  the  report  presents  the  specific  details  of  the  methodology  survey  that  we  have 
conducted.  The  survey  is  organized  by  the  ‘‘short  list"  of  methodologies  presented  in  the  previous 
section.  This  list  contains  eight  groups  of  authors  whose  work  we  believe  to  be  the  most  significant 
and  representative  of  a  larger  body  of  relevant  authors.  Following  the  tabular  comparison  are 
extended  reviews  for  the  key  authors  summarized  in  the  table. 

2.1  Summary  Comparison  Table 

Tkble  1  summarizes  the  results  of  the  methodology  survey.  The  table  is  formated  with  key  features 
listed  in  the  leftmost  column,  and  the  reviewed  methodolopes  listed  along  the  top  row.  The  features 
are  organized  into  seven  major  categories.  Each  of  these  categories  is  described  briefly  below  In 
the  subsections  which  follow,  detailed  reviews  of  the  summarized  work  are  presented. 

In  Table  1,  the  features  under  the  category  “Models  of  Concurreacy  Supported”  refer  to  the 
major  forms  of  concurrency  supported  in  spedfieation  and  programming  languages.  These  features 
are  the  union  of  those  features  used  to  describe  concurrent  execution  in  the  current  literature. 
“Concurrency  Properties”  refer  to  attributes  of  a  concurrent  program  that  should  be  specifiable 
and  verifiable.  Again,  these  features  are  drawn  from  the  current  literature,  in  particular  [AS83]. 
The  feature  for  “Granularity  of  Concurrency”  refers  to  the  lexical  level  of  a  program  at  which 
concurrency  is  specifiable;  it  should  be  noted  that  some  languages  support  specification  at  more 
than  one  level.  “Development  Phases  Supported”  refers  to  the  standard  phases  of  the  software  life 
cycle  that  are  supported  by  the  systems  under  review.  The  “Formt  of  Logic”  category  includes 
the  most  conamon  forms  supported  in  compntcr.aided  verification  systems.  BOL  (for  Higher-Order 
Logic)  and  Boyer-Moore  (for  the  inventors’  names)  are  logics  particular  to  two  computer-based  logic 
systems.  The  “Quantitative”  and  “Qualitative  Measures”  categories  include  general  features  of  the 
usage  and  design  of  the  methodologies.  The  measures  are  based  on  our  actual  experience  with  the 
methodologies  together  with  experience  reported  in  the  bterature.  Finally,  the  “Systems  Features” 
category  relates  to  those  methodologies  for  which  implemented  system  support  is  available;  this 
category  is  not  applicable  to  those  methodologies  that  are  not  3ret  implemented. 
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Table  1  Notes: 


1.  Chen  and  Hoare  have  extended  the  original  Hoare  logic  to  support  the  concurrency  features  of  CSP. 

2.  The  level  of  concurrency  in  the  Chen  and  Yeh  methodology  is  lexically  at  the  statement  level,  but 
semantically  interaction  is  only  enforced  at  statements  dealing  with  port  interaction,  which  means 
that  the  granularity  is  really  more  at  the  process  level. 

3.  Verification  in  the  Chen  and  Yeh  approach  focuses  on  processes  and  interprocess  communication; 
verification  of  other  aspects  of  the  program  are  not  considered  but  could  presumably  be  handled  with 
existing  techniques. 

4.  The  methodology  of  Flon  and  Susuki  is  baaed  on  the  transformation  of  concurrent  programs  to  sequen* 
tial  programs,  after  which  the  verification  is  carried  out  using  sequential  verification  techniques;  in 
this  sense  the  methodology  does  not  support  any  model  of  concurrency  directly,  though  the  concurrent 
programs  that  are  transformed  are  assumed  to  use  a  shared  variable  model. 

5.  Goguen’s  OBJ  language  docs  not  support  any  model  of  concntrency  explicitly.  Rather,  Goguen’s 
goal  for  the  realisation  of  concurrent  programs  is  to  construct  a  specification  which  abstracts  away 
any  explicit  details  of  concurrency,  but  which  is  stated  in  a  functional  language  that  is  amenable 
to  translation  into  a  form  that  is  concurrently  executable.  That  is,  Goguen’s  goal  is  to  move  all 
consideration  of  concurrent  execution  out  of  the  hands  of  the  specifier/programmer  into  the  realm  of 
the  language  translator.  Our  work  on  extensions  to  0BJ3  includes  features  that  do  allow  the  explicit 
representation  of  concurrency  within  the  OBJ  framework.  Details  of  OBJ  and  out  extensions  to  it  are 
covered  in  later  sections  of  the  report. 

6.  See  note  5. 

7.  Since  OBJ  is  a  fully  functional  language,  there  is  no  clear  distinction  between  a  function  invocation, 
a  statement,  and  an  expression. 

8.  Theorem  proving  support  is  based  on  the  rewrite  execution  capability  of  OBJ.  However,  there  is  not 
much  in  the  way  of  other  proof  management  facilities,  such  as  proof  management,  builUin  support  for 
induction,  etc.  We  are  currently  adding  some  of  these  capabilities  to  OBJ. 

9.  Although  Jones’  and  Owicki’s  methodologies  focus  explicitly  on  the  shared* variable  level  of  concur¬ 
rency,  aspects  of  his  methodology  are  applicable  to  other  concurrency  models. 

10.  Jones  suggests  that  temporal  logic  should  be  incorporated  into  his  methodology. 

11.  Luchham  and  coauthors  hint  at  (wish  for)  proof  rules  for  their  Temporal  Specification  Language  (TSL) 
methodology. 

12.  The  Luckham  TSL  methodology  is  based  on  Ada  which  does  not  support  asynchronous  message 
passing. 

13.  Based  on  Ada,  TSL  granularity  is  at  the  task  level. 

14.  TSL  is  based  on  a  form  of  temporal  logic  combined  with  path  expressions. 

15.  Coding  is  supported  to  tbe  process  level,  but  not  below. 

16.  Owicki’s  methodology  adds  history  and  other  auxilliary  variables  to  the  base  propositional  logic. 

17.  Aa  described  below,  we  have  implemented  some  extensions  within  the  HOL  system  to  support  a  form 
of  cquational  logic,  and  this  is  an  area  of  continuing  research. 

18.  In  papers  on  the  Larch  system,  the  authors  describe  the  interface  from  the  Larch  cquational  logic 
to  predicate  logic,  but  it  is  unclear  from  system  descriptions  if  the  implemented  system  supports 
machine-based  predicate  logic. 


2.2  Barringer  and  Mearns 

2.2.1  Overview 

Barringer  and  Mearns  propose  axiomatic  proof  rules  for  the  partial  correctness  and  deadlock  free 
in  Ada  tasks.  The  work  is  based  on  proof  methods  for  CSP  proposed  by  Apt,  Francez  and  de 
Roever.  In  this  approach,  the  correctness  of  a  parallel  program  is  proved  in  two  steps.  First,  each 
process  of  the  parallel  program  is  proved  in  isolation  as  an  individual  sequential  program.  Then,  a 
cooperation  proof  is  made  to  ensure  that  the  interaction  between  processes  does  not  invalidate  the 
sequential  proofs. 

2.2.2  Technical  Discussion 

The  following  assumptions  are  made  about  Ada  programs: 

1.  tasks  do  not  share  global  variables 

2.  task  does  not  call  its  own  entries 

3.  all  constructs  terminate  normally 

4.  calls  to  subprograms  have  no  side  effects 

5.  assignments  have  no  side  effects 

6.  no  two  tasks  have  the  same  name 

In  this  methodology,  the  correctness  of  a  parallel  program  is  defined  in  term  of  a  global  assertion 
GI  that  asserts  variables  from  all  tasks.  Since  tasks  are  assumed  not  to  share  global  variables  and 
since  rendezvous  is  the  only  communication  mechanism  in  Ada,  the  proof  rules  are  centered  on 
axioms  of  the  rendezvous  mechanism. 

Barringer  and  Mearns  define  the  following  terms  in  order  to  facilitate  their  axioms: 
Input/output  commands  (10):  they  are  just  entry  calls  and  accept  statements.  Two  10  com¬ 
mands  are  said  to  match  if  one  command  is  an  entry  call  to  the  other’s  accept  statement. 

Bracketed  sections  (BS):  these  are  sections  of  the  program,  delimited  by  ’<’  and  ’>’  of  the 
form: 

S\\I0\  S2\ 

where  sj  and  sj  are  Ada  constructs  that  do  not  include  any  10  command. 

The  global  invariant  Gl  needs  not  hold  within  a  bracketed  section  BS  but  no  variable  free  in  GI 
may  change  outside  a  BS.  Two  bracketed  sections  match  if  they  contain  matching  10  commands. 
Every  10  in  a  program  must  appear  in  a  BS  and  must  match  with  at  least  one  other  10. 

Since  the  body  of  an  Ada  accept  statement  may  contain  entry  calls  and/or  accept  statements, 
a  bracketed  section  may  be  nested.  Barringer  and  Mearns  propose  that  auxiliary  variables  can  be 
used  to  incorporate  all  the  “intermediate  global  assertions”  into  GI. 

Co-operation:  Given  proofs  of  {P^}  Ti  {Qi}  for  all  tasks  Tj,  1  <  x  <  n,  considered  in  isolation, 
the  n  local  proofs  are  said  to  co-operate  if 

1.  the  assertions  used  in  the  local  proof  of  {P,}  T,  {Q,}  have  no  free  variables  subject  to  change 
in  T,  (  i  j  )  ; 

2.  {pre(BSi)  ^  pre{BS2)  A  G/}  BSi  HBSj  {post(B5i)  A  post{BS2)  A  G/}  holds  for  all  matching 
pairs  of  bracketed  sections  BSi  and  BS2 
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The  paper  also  discusses  how  to  prove  blocking  free  and  deadlock  free.  The  proof  methods  are 
similar  to  the  methods  of  Owicki  &  Gries  and  Apt  ct  al. 

A  summary  of  the  proof  rules  involving  Ada  rendezvous  is  as  following: 

Entry  call 
{P}  T,.E,  {(?} 


Accept  statement 
{P}  accept  Ej{. . .)  do  s]  end  {<3} 

General  communication  rule 
_ {P[/.o/Q.o]  a  fi„  =  Q.n}  ■»  {g} _ 

{P] 

“P i-P ®»o>  ^out)|l 

accept  Ejifin  ;  tn  out . . . ;  :  out ...)  do  s;  end; 

f tof  ^out/fout\) 

Parallel  composition  rule 

for  all  tasksT,,  1  <  i  <  n,  proofs  {P,}  Ti  {(?,}  cooperate 

{Pi a...ap„ag/}  Ti||...||r« {(?!  A...A q„agi} 
Formation  rule  ^ 

{P}  {Pi},{Pi}  /O1II/O2  {gi}.{Qi}  52:54  {Q} 

{P}  <  BSi  >  II  <  BS2  >  {(?} 
whereBSi  =  si;I0\,S2  and  BSj  =  S3;/02;S4 


Transformation  rule 
{P}  r’i||r’2i|...||r’n  {g} 

{p}  ri||r2l|...||Pn  {<?} 


2.2.3  Critical  Remarks 

The  methodology  can  be  used  to  prove  some  interesting  properties  of  Ada  tasks  such  as  blocking 
free,  deadlock  free,  and  termination.  However,  it  is  not  clear  how  the  method  can  be  generalized 
to  prove  Ada  tasks  that  communicate  through  shared  variables.  In  general,  Barringer  and  Mearns 
methodology  is  just  a  retrospective  fitting  of  proofs,  it  cannot  be  used  as  a  development  tool. 


2.3  Chen  and  Hoare 

2.3.1  Overview 

Zhou  Chao  Chen  and  C.A.R  Hoare  presented  a  paper  entitled  Partial  Correctness  of  Communi¬ 
cating  Processes  which  was  almost  immediately  followed  by  a  paper  by  C.A.R.  Hoare,  entitled 
A  Calculus  of  Total  Correctness  for  Communicating  Processes.  In  these  two  papers  they  intro¬ 
duce  a  programming  notation  used  to  “...describe  the  behavior  of  groups  of  parallel  processes, 
communicating  with  each  other  over  a  network  of  named  channels.  " 

The  methodology  presented  in  these  papers  outlines  the  necessary  proof  rules  and  techniques 
necessary  to  prove  the  desired  behaviors.  Each  channel  of  communication  has  an  auxiliary  variable 
associated  with  it.  This  variable  (or  trace)  is  an  ordered  sequence  consisting  of  all  messages 
communicated  over  the  channel,  direction  of  the  message  is  unspecified.  In  Hoare’s  paper  he  also 
added  an  auxiliary  variable  to  each  process,  one  for  each  channel  connected  to  that  process.  This 
variable  is  the  ready  state  of  the  process.  If  the  process  is  ready  to  communicate  a  message  along 
the  channel  it  contains  the  value  to  be  sent,  if  it  is  ready  to  receive  a  message  along  the  channel 
the  variable  contains  the  set  of  all  possible  messages  (the  type  class)  it  can  receive. 
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Proofs  in  this  methodology  deal  mainly  with  a  hierarchical  development  of  the  system.  Prop¬ 
erties  (behaviors)  of  the  outermost  layer  is  specified  in  terms  of  sequence  of  values  communicated 
over  the  external  channels.  Once  the  restrictions  on  the  channels  are  shown  to  maintain  these 
properties,  we  then  implement  the  lower  layer  in  terms  of  parallel  communicating  processes,  or  in 
actual  code.  In  the  processes  case,  we  must  specify  properties  about  the  internal  communication 
channels.  In  both  cases  we  must  show  that  the  implementation  maintains  the  properties  specified  at 
the  higher  level.  This  allows  us  to  work  with  a  small  group  of  proofs  at  a  time  and  use  a  systematic 
top-down  development /proof  of  the  system. 

2.3.2  Technical  details 

To  manipulate  the  proofs,  we  need  to  use  the  following  “health”  rules  and  proof  rules: 

(HI)  PstXTRVE 
(H2)  -.(P  sat  FALSE) 

(H3) 

R=>S 

(P  sat  P)  =>  (P  sat  R) 

If  n  is  not  a  channel  variable,  and  does  not  occur  in  P: 

(H4)  (Vn  :  N.P  sat  P(n))  =  (P  sat  (Vn  :  N.R(n))) 

The  following  is  a  list  of  proof  rules  and  inference  rules  that  Hoare  uses  when  proving  properties 
of  the  processes.  (Rl)  Output 

((c!c  — *  P)  sat  P)  =  {R\{  ) /past,  {e}/c.Teady,0/ ready] 

ii  P  sat  (P({e)c.past/c.past]) 

Let  P  be  an  assertion  not  containing  x.: 

(R2)  Input 

((c?i  :  M  -*  P(z))  sat  R)  S  (P((  )/past,  M/c.Teady,0/Teady] 

&  Vi  ;  M.(P{x)  sat  P[(i)c.post/c.past])) 

Define  the  ‘fixed  point’  of  F  to  be  np.F{p)  —  P(pp.P(p)). 

Also  define  P  t  (P  restricted  to  n)  to  be:  P  }  n  ^  (#a.past  -t- - (-  i/z.past  >  n)\/  R)  where  #5 

stands  for  the  length  of  the  sequence  s. 

(R3)  Recursion 

(p  sat  (P  t  n))  =>  (P(p)  sat  (P  t  n  -I-  1)) 

Mp  F(p)  sat  P 

(R4)  Stop 

{STOPa  sat  P)  =  R{Q/ready,{  )/pasi] 

(R5)  Disjoint  Parallelism 
(P  sat  5)  $  {Q  sat  T) 

(P||<?)  sat  (5  &  T) 

In  the  review  of  this  paper  by  Barringer,  Barringer  uses  as  an  example  a  version  of  a  Bubble 
Lattice  Sort.  Initially  he  specifies  the  properties  of  the  Sort  process.  Then  Sort  is  defined  as  a 
parallel  composition  of  Comp  processes  with  the  IN  and  OUT  channels  appropriately  connected. 
Now,  using  the  inference  rules  we  can  prove  that  the  above  decomposition  actually  implement  the 
specification  of  Sort. 

Once  we  get  to  the  level  of  code,  we  can  use  the  inference  rules  presented  by  Chen  and  Hoare, 
or  the  modified  versions  of  Hoare,  and  use  these  around  the  communication  primitives  in  the  code. 
(The  code  in  this  case  contains  CSP-style  communication  primitives).  Other  portions  of  the  code 
can  be  verified  separately  using  the  standard  axiomatic  techniques  of  Hoare. 
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2.3.3  Critical  Remarks 


The  method  presented  by  Chen  and  Hoare,  and  later  modified  by  Hoare,  is  a  good  hierarchical 
development  of  a  proof  methodology.  We  can  work  from  a  high-level  description  of  the  process 
down  to  the  code  level. 

Using  these  techniques  we  can  prove  absence  of  deadlock,  termination,  fairness.  This  model 
does  not  seem  to  be  able  to  be  proven  complete,  and  has  yet  to  be  proven  consistent.  It  also  contains 
no  way  of  proving  that  a  process  P  is  non-deterministic.  In  other  word  if  P  sat  R  then  there  exists  a 
deterministic  process  Q  such  that  Q  sat  R.  Hoare  also  states  that  the  axiomatization  of  sequential 
composition,  local  variables,  and  assignment  may  cause  some  difficulty  in  this  methodology. 

2.4  Chen  and  Yeh 

2.4.1  Overview 

The  model  presented  in  the  paper  of  Chen  and  Yeh  is  based  on  events  and  their  relationships.  An 
event  is  described  as  . .  an  instantaneous,  atomic  state  transition  in  the  computation  history  of  a 
system.” 

Using  this  event-based  model  they  can  specify  interrelationships  between  processes  based  on 
the  ordering  of  these  processes.  If  an  ordering  is  not  specified  this  impbes  an  implicit  concurrent 
behavior  amongst  the  processes. 

They  present  an  Event  Based  Specification  Language  (EBS)  as  a  tool  for  formciUy  specifying 
systems  using  the  event- based  model.  This  language  is  based  on  partial  orders  and  first-order  pred¬ 
icate  calculus.  The  hope  is  that  using  EBS,  the  developer  can  avoid  some  of  the  more  cumbersome 
details  involved  in  writing  the  specification  when  using  a  trace  or  temporal  based  model,  yet  still 
have  the  ability  to  express  everything  those  models  allows  him  to  express. 

2.4.2  Technical  Discussion 

To  implement  an  ordering  between  events  the  develop  an  “precedes”  relation  denoted  by  This 

is  a  partial  ordering  that  helps  remove  the  system  clock  requirements  necessary  for  a  total  ordering. 
If  Cl  and  cj  are  events  in  the  system  and  €\  — ♦  e^  then  C]  precedes  ej  by  some  measure  of  time. 
They  use  this  relation  and  specify  the  transitivity,  irreflexivity,  and  antisymmetry  properties  of  it. 

Concurrency  is  specified  by  stating  that  if  -•(«]  — »  ei)  A  ->(e2  -*  ^i)  then  ej  and  e2  are 
concurrent. 

They  develop  an  “enables”  relation  which  denoted  by  =>  that  states  if  cj  =>  C2  then  the 
existence  of  event  cj  will  cause  the  occurrence  of  event  and  some  time  in  the  future.  This 
relation  is  also  irreflexive,  transitive,  and  antisymmetric. 

Finally  they  specify  the  system,  environment  and  interface  ports.  Where  the  system  interacts 
with  the  environment  through  the  interface  ports.  Associated  with  each  port  is  a  history  of  uniquely 
identified  interface  events  .which  creates  a  total  ordering. 

After  presenting  the  above  definitions  and  relationships  they  present  details  of  EBS  for  spec¬ 
ifying  the  behavior  of  a  distributed  system.  This  language  consists  of  the  following  operators  and 
precedence  rules: 

•  unary  operators;  V  (for  all),  3  (there  exists),  and  ->  (logical  negation); 

•  relation  operators;  6  (belongs  to),  =  (equivalent),  =  (equals  to),  =>  (enables),  and  — • 
(precedes); 
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•  logical  operators:  V  (logical  or)  and  A  (logical  and); 

•  implication:  >  (logical  implication)  and  <  #  >  (two  way  logical  implication). 

An  example,  given  in  the  paper,  is  of  a  reliable  transmission  system  with  input  port  A  and 
output  port  B.  The  equation  specifies  the  property  that  for  some  message  cj  that  is  sent  before 
message  aj  then  it  is  received  before  U}: 

(•  RT15(A,B):  no  out-of-order  messages  •) 

Voi,tt2  €  A,b\,b2  €  B 
^  (12  ^  b2 

#  >  (ai  -♦  oj  A  hi  -♦  h2)V 
(sx  s  4}  A  6x  =  h3)v 
(flj  —*  Cl  A  b2  bi^ 

Now  that  we  have  specified  properties  of  the  system,  we  can  use  these  as  building  blocks  for 
more  complicated  systems.  Properties  of  the  more  complicated  systems  can  be  proven  using  the 
properties  specified  at  the  lower  levels. 

They  state  that  the  EBS  language  has  the  foUowing  benefits: 

•  Formality.  Partial  ordering  relations  and  first  order  predicate  calculus  guarantee  this 

•  Generality.  Safety,  liveness,  data-related  and  control-related  properties  can  be  specified  and 
verified. 

•  Accuracy:  The  inherent  behavior  of  distributed  systems  is  represented  by  the  lack  of  ordering 
among  events;  mutual  exclusion  is  specified  by  the  preceded  operation. 

•  Orthogonality.  Properties  are  specified  separately,  which  makes  specification  minimal  and 
extensible. 

2.4.3  Critical  Remarks 

A  trace  (history  sequence)  of  CSP  can  be  seen  as  a  sequence  of  events  yet  properties  specified  in 
EBS  are  often  much  easier  to  manipulate  than  using  traces.  This  should  therefore  allow  a  greater 
flexibility  and  ease  of  specification  compared  to  the  other  methodologies. 

The  examples  presented  in  the  paper  seemed  to  be  designed  bottom-up  although  the  method¬ 
ology  apparently  can  be  used  for  a  top  down  hierarchical  design  and  specification  of  a  system. 
Further  work  with  this  methodology  and  development  of  our  canonical  model  using  this  method  is 
recommended. 

2.5  Flon  and  Suzuki 

2.5.1  Overview 

Flon  and  Suzuki  propose  that  a  parallel  program  whose  processes  communicate  through  shared 
memory  can  be  converted  to  an  equivalent  non-deterministic  sequential  program,  and  that  by 
proving  some  interesting  properties  of  the  non-deterministic  program,  we  can  indirectly  verify  the 
semantics  on  the  parallel  version.  The  properties  that  cart  be  proved  are  invariance,  potentiality, 
inevitability,  absence  of  blocking,  absence  of  deadlock,  and  absence’of  starvation.  Flon  and  Suzuki 
provide  a  procedure  and  a  set  of  inference  rules  to  facilitate  the  program  conversion  and  the  proving 
processes.  The  inference  rules  are  based  on  weakest  precondition  predicate  transformation. 
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2.5.2  Technical  Discussion 

A  non-deterministic  sequential  program  is  equivalent  to  a  parallel  program  if  for  any  execution 
sequence  of  the  non-deterministic  sequential  program,  there  is  a  corresponding  execution  sequence 
in  the  parallel  counterpart  such  that  values  of  variables  in  the  parallel  version  have  the  same 
history  sequence.  In  Flon  and  Su2uki  method,  a  parallel  program  composed  from  the  cobegin- 
coend  construct  can  be  converted  to  a  sequential  program  denoted  by  the  REP  construct.  The 
REP  construct  is  a  repetitive  guarded  command  and  can  only  be  terminated  by  an  exit  command. 
REP  ::=  rep  Bi  -  SiHBj  ^  52||...||B„  -  5„  per 
The  conversion  procedure  is  as  following.  First  of  all,  the  entire  parallel  program  is  converted 
to  an  indivisible  form  by  introducing  variables  local  to  each  process.  Then,  each  statement  in 
the  parallel  program  is  transformed  to  an  equivalent  statement  using  the  rules  provided  by  Flon 
and  Suzuki.  The  rules  cover  the  transformations  of  cobegin-coend  construct,  block  construct, 
assignment  construct,  conditional  construct,  and  loop  construct. 

Flon  and  Suzuki  also  provide  a  set  of  inference  rules  to  assert  the  weak  correctness,  blocking 
free,  deadlock  free,  and  starvation  free  properties  of  a  non-deterministic  sequential  program,  and 
claim  that  these  properties  can  be  applied  to  the  parallel  version.  The  following  is  a  summary  of 
the  inference  rules; 

Invariance  I 

vie  :  1  <  fc  <  n  :  (7  A  Bx  ^  'U'^p(Bfc,7)),7  =>  R 
I  ^  wip(REP,R) 

where  wlp  is  Dijkstra’s  weakest  liberal  precondition,  i.e.,  the  construct  is  not  required  to  terminate, 
wip  is  the  weakest  precondition  for  invariance 
Potentiality 

-’t3(0),Q(m-t-  1)  A  ->72  =>  3k  :  1  <  k  <  N  :  (B*  A  wp(Sk,Qi‘m.))) 

Q{m)  =>  wpp{REP,R) 

where  wpp  is  the  weakest  precondition  for  potentiality. 

Inevitability 

~'Q(0).<?(^+  1)  A  =»  3t  :  1  <  I  <  TV  ;  (Bt  =>  ■wp{Sk,Q{Tn))) 

Q(m)  =>  wep{REP,R) 

where  wep  is  the  weakest  precondition  for  inevitability. 

Blocking  free 

Vit  :  1  <  it  <  A’  :  (7  A  Bfc  =>  iop(5fc,  7)),  7  =>  3it  :  1  <  it  <  TV  :  B* 

7  =>  wbp{REP) 

where  wbp  is  the  weakest  precondition  for  blocking  free. 

Deadlock  free 

'^k  :  1  <  k  <  N  :  (I  ^  B k  ^  iyp(S*,7)),7  =>  wpp{REP,  B,)  V  Q 
7  =>  wdpjiREP) 

where  Q  is  the  disjunction  of  all  the  guards  of  exit  commands,  and  wpp  is  the  weakest  precondition 
for  deadlock  free. 

Starvation  free 

VI:  :  1  <  <  7/  ;  (7  A  Bfc  =>  wp{Sk,  7)), 7  =>  wep{REP,  Bj)  V  Q 

I  =>  wspj{REP) 

where  wsp  is  the  weakest  precondition  for  starvation  free. 

2.5.3  Critical  Remarks 

Since  the  primary  objective  of  the  Flon  and  Suzuki  methodology  is  to  prove  some  interesting  prop¬ 
erties  of  an  existing  parallel  program,  the  methodology  cannot  be  used  for  the  hierarchical  program 
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development,  and  cannot  be  used  in  conjunction  with  program  development.  The  application  of 
the  proof  rules  is  straightforward;  but  obtaining  a  good  invariance  and  a  valid  metric  is  not  a  trivial 
task  and  requires  a  complete  knowledge  of  behavior  of  other  processes. 

It  is  questionable  whether  the  method  can  be  applied  to  real  examples.  The  parallel  to  se¬ 
quential  program  conversion  algorithm  seems  too  tedious  to  follow,  and  some  optimization  should 
be  performed  to  ease  the  proving  process. 

2.6  Halpern  and  Owicki 

2.6.1  Overview 

Halpern  and  Owicki ’s  method  consists  of  three  steps:  (1)  Model  a  parallel  program  as  a  set  of 
modules  that  interact  by  procedure  calls  (2)  Verify  module  properties  using  standard  sequential 
techniques  (3)  Compose  modules  into  a  system.  Module  specifications  consist  of  an  invariant,  a 
commitment,  and  service  specifications.  The  invariant  refers  to  safety  properties  and  the  com¬ 
mitment  refers  to  liveness  properties  (using  temporal  logic).  The  service  specifications  correspond 
to  each  exportable  procedure  and  consist  of  preconditions  and  postconditions  which  refer  to  both 
safety  and  liveness  properties,  and  of  a  liveness  condition,  which  states  the  conditions  under  which 
procedure  termination  is  guaranteed. 

Temporal  logic  is  an  important  tool  in  this  technique.  Temporal  logic  is  an  extension  of 
ordinary  logic  to  include  time.  Halpern  and  Owicki’s  notation  includes: 

OP  At  some  time  P  will  be  true  (eventually) 

□P  P  will  always  be  true  (henceforth) 

OO  P  P  will  be  true  infinitely  often 
A  B  Temporal  implication;  if  A  is  true,  OB 

In  addition  to  temporal  logic,  Halpern  and  Owicki  make  use  of  auxiliary  variables,  histories, 
and  private  variables.  Auxiliary  variables  are  used  in  specifications  and  proofs;  they  are  included 
only  for  convenience  in  reasoning  about  a  program.  History  variables  are  a  special  class  of  auxil¬ 
iary  variables;  they  are  unbounded  sequences  used  for  recording  interactions  between  modules.  A 
variable  x  which  is  ‘private'  in  module  M  will  have  one  instance  for  each  module  calling  M.  The 
notation  x[C)  denotes  a  module  referring  to  C’s  version  of  x;  x[*)  denotes  a  module  referring  to  its 
own  version  of  x. 

2.6.2  Technical  Discussion 

Halpern  and  Owicki’s  goal  for  this  system  is  to  ensure  that  the  proof  that  a  module  meets  its 
specifications  is  independent  of  the  code  of  other  modules  in  the  systems.  To  achieve  this,  it  is 
important  that  each  module’s  assertions  be  robust  (i.e.,  other  modules  cannot  make  them  false). 
This  is  done  by  restricting  assertions  in  each  module  M  to  variables  local  to  M.  Thus,  a  module’s 
invariant  and  commitment  clauses  use  only  local  variables  and  the  service  specifications  use  only 
procedure  parameters  and  private  variables  of  the  called  module.  Furthermore,  assertions  are 
monotonic  (i.e.,  once  true  they  cannot  be  made  false). 

For  verification  purposes,  the  invariant  of  a  simple  module  must  hold  when  that  module  is 
ready  to  interact  with  another  module  either  by  accepting  or  initiating  a  procedure  call.  For  com¬ 
pound  modules,  specifications  are  verified  from  the  specifications  of  the  components.  Invariant  and 
commitment  are  shown  to  be  implied  by  the  conjunction  of  the  component  invariants  and  commit¬ 
ments.  Service  specifications  may  be  proved  from  the  code  or  carried  over  from  the  component. 
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Note  that  it  is  always  possible  to  assign  values  to  the  variables  that  are  not  open  such  that  the 
invariant  is  satisfied. 

2.6.3  Critical  Remarks 

In  Halpern  and  Owicki’s  method,  the  proof  process  is  simplified  since  proofs  from  code  involve 
oniy  sequential  reasoning.  In  addition,  an  individual  module’s  specification  can  be  verified  with¬ 
out  consideration  of  other  modules  (except  service  specifications).  Finally,  composition  of  system 
specifications  is  based  on  logical  reasoning,  not  the  code  that  it  is  based  upon. 

2.7  Jones 

2.7.1  Overview 

Jones  proposes  a  rigorous  method  for  developing  a  program  comprising  tasks  which  execute  in 
parallel  and  interfere  with  each  other.  A  rigorxtus  method  relies  on  underlying  mathematical  ideas 
but  uses  these  foundations  for  less  formal  arguments.  The  approach  taken  is  intended  to  be  precise 
without  being  bulky.  When  complete  formality  is  required,  the  necessary  details  can  be  added. 

In  a  parallel  program,  a  task  interferes  with  another  by  modifying  a  variable  accessible  to 
both  or  by  message  passing.  Jones  emphasizes  shared-storage  parallelism.  There  seems  to  be  some 
confusion  concerning  the  method’s  applicability  to  message-passing  parallelism.  However,  message 
passing  can  be  considered  as  a  restricted  form  of  shared-storage  access.  Indeed,  sending  a  message 
to  a  task  amounts  to  modifying  its  message  queue  in  accordance  with  the  intertask  protocol.  This 
protocol  invariably  involves  semaphore  sequencing. 

Programs  are  developed  (implemented)  by  the  recursive  application  of  operation  decomposition. 
Operation  is  a  noncommittal  term  for  aprocedure,  a  function,  or  even  a  statement.  As  each  high- 
level  operation  is  implemented  in  terms  of  low-level  operations,  only  the  specifications  of  the  low- 
level  operations  are  necessary  to  justify  the  decisions  embodied  in  the  decomposition.  This  is 
in  contrast  to  methods  requiring  a  completely  coded  solution.  At  the  leaves  of  the  development 
tree,  operations  are  implemented  by  programming-language  statements.  Their  effects  must  also 
be  specified.  Thus,  for  a  thorough  specification,  the  language  employed  should  enjoy  a  formal 
semantics,  preferably  provided  in  a  style  similar  to  that  of  Jones.  Although  Jones  uses  Ada  for 
examples,  the  method  is  not  language  dependent. 

Specifications  are  operation  stubs  that  include  a  specification  block.  A  stub  is  an  operation  type 
signature  and  a  list  of  global  variables  that  need  to  be  accessed  by  the  operation.  A  specification 
block  comprises  a  pre-condition,  post-condition,  rely-condition,  and  guarantee-condition.  Jones’ 
main  contribution  is  the  complementary  interaction  of  rely-conditions  and  guarantee-conditions. 

2.7.2  Technical  Discussion 

Specifications  are  written  using  pre-conditions,  post-conditions,  rely-conditions,  and  guarantee- 
conditions.  Every  operation  in  a  problem  decomposition  has  one  of  each;  if  not,  defaults  apply. 
But  before  these  are  discussed  more  precisely,  we  need  a  few  more  definitions. 

A  state  is  a  collection  of  named  values.  More  concretely,  a  task’s  state  is  the  collection  of 
variable  values  explicitly  and  implicitly  accessible  by  the  task.  Thus,  an  operation  can  be  viewed 
as  a  function  from  one  state  to  another.  However,  Jones  emphasizes  that  while  an  operation 
can  change  a  value  within  a  state,  it  cannot  change  the  structure  (i.e.,  add  or  delete  variables). 
Specifications  employ  predicates  on  states  —  functions  on  states  with  Boolean  range.  A  relational 
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predicate  on  states  is  a  function  on  two  states  with  Boolean  range  whose  arguments  are  recognized 
as  initial  and  final  states.  The  final  state,  as  well  as  its  components,  are  denoted  by  priming. 
For  example,  p(<r,  o')  =  true  is  a  relational  predicate  named  p  on  initial  state  a  and  final  state  o' 
defined  to  be  true  (i.e.,  always  satisfied).  Although  relational  predicates  are  no  more  powerful  than 
plain  predicates,  Jones  claims  their  use  simplifies  the  specification  of  larger  problems. 

A  pre-condition  is  a  predicate  on  a  single  state  specifying  over  what  subset  of  all  possible 
states  an  operation  must  succeed.  If  its  pre-condition  is  not  satisfied,  an  operation  is  completely 
unconstrained  (however,  an  error  message  would  be  appreciated). 

A  post- condition  is  a  relational  predicate  specifying  the  required  relationship  between  initial 
and  final  states.  It  describes  the  effect  of  an  operation  on  a  state  satisfying  the  pre-condition.  An 
appropriate  post-condition  for  a  nonterminating  operation  (e.g.,  an  operating  system)  is  somewhat 
arbitrary, 

A  rely-condition  is  a  relational  predicate  specifying  how  other  tasks  can  modify  the  state. 
Here,  the  initial  state  is  that  before  modification  and  the  final  state  is  that  after  modification.  A 
rely-condition  must  hold  across  every  interfering  modification  to  the  state.  Curiously,  a  task  may 
violate  its  own  rely-condition  yet  satisfy  its  specification.  This  phenomenon  occurs,  for  example, 
when  many  tasks  are  allowed  to  read  a  global  variable,  but  only  one  task  is  allowed  to  change  its 
value.  The  writer  relies  on  constancy  but,  of  course,  it  may  modify  the  variable. 

A  guarantee-condition  is  a  relational  predicate  specifying  how  the  task  containing  it  can  modify 
the  state.  Once  again,  the  initial  state  is  that  before  modification  and  the  final  state  is  that 
afterwards.  A  guarantee-condition  must  hold  across  all  modifications  to  the  state  made  by  the  task 
containing  it. 

Intuitively,  pre-conditions  and  post-conditions  must  hold  once  per  operation  execution;  the  pre¬ 
condition  on  entrance  and  the  post-condition  on  exit.  In  contrast,  rely-conditions  and  guarantee- 
conditions  must  hold  at  (potentially)  many  times  during  operation  execution.  Any  time  a  variable 
which  is  accessible  to  multiple  tasks  is  modified,  the  guarantee-condition  of  the  modifying  operation 
must  hold  and  the  rely-condition  of  all  operations  having  access  to  the  variable  must  hold.  This 
potential  complexity  is  bravely  represented  in  the  proof  obligations  to  come. 

One  way  to  view  rely-conditions  and  guarantee-conditions  is  as  concurrent  versions  of  pre¬ 
conditions  and  post-conditions,  respectively.  Another  is  as  invariants  holding  only  at  certain  times. 

A  partial  specification  —  one  missing  one  or  more  of  the  four  conditions  —  assumes  default 

conditions.  These  are  shown  below. 
pre-Default{c)  o  true 

post-Default{a,o')  o  true 
rely- Default  {a,  o')  00  =  0' 
guar-Default{o,o')  o  true 

The  default  pre-condition  specifies  an  operation  succeeding  on  any  state.  Such  an  operation  is 
analogous  to  a  total  function.  The  default  post-condition  does  not  constrain  an  operation’s  modi¬ 
fication  of  the  state  at  all.  Such  an  operation  can  modify  every  accessible  variable  or  do  nothing. 
The  default  rely-condition  assumes  complete  noninterference,  as  in  a  sequential  environment.  The 
default  guarantee-condition  guarantees  nothing,  any  interference  is  allowed. 

Recall  that  Jones’  method  is  for  developing  a  program  by  decomposing  a  problem.  The  in¬ 
teresting  decomposition  steps  are  those  involving  the  implementation  of  an  operation  by  a  set 
of  suboperations  that  execute  concurrently.  Call  the  main  operation  OP  and  the  suboperations 
Ti,  Tj, . . .,  T„.  In  order  to  prove  that  the  development  step  is  correct,  several  proof  obligations 
must  be  satisfied.  Each  is  discussed  below. 
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The  tasks  must  rely  on  no  more  than  the  main  operation: 
rely-OP{gl,gl')  =>  (V:  :  1  <  t  <  n  :  rely-T,{{gl,loc),{gl',loc))). 

Here,  gl  is  the  state  accessible  to  operations  with  access  to  OP.  In  contrast,  loc  comprises  the  local 
variables  of  OP  —  those  shared  by  the  suboperations.  Since  loc  represents  variables  inaccessible  to 
operations  outside  of  OP,  it  cannot  be  modified  by  those  operations,  and  the  loc  component  of  the 
final  state  of  each  task’s  rely-condition  is  implicitly  guaranteed  to  be  identical  to  the  loc  component 
of  the  initial  state.  Thus,  it  need  not  be  primed. 

Independently,  the  tasks  must  guarantee  what  the  main  operation  guarantees: 

(3i :  1  <  i  <  n  :  guar-T,{{gl,loc),{gl',loc')))  =>  guar-OP{gl,gl'). 

Here,  loc  is  comprises  variables  which  are  accessible  to  the  task  making  the  guarantee.  Satisfaction 
of  this  guarantee  might  involve  modifying  such  a  variable.  Thus,  in  the  final  state  loc  is  primed. 

Each  task’s  guarantee-condition  must  be  at  least  as  strong  as  every  other  task’s  rely-condition 
—  the  tasks  must  be  able  to  coexist: 

(Vi,j  :  1  <  i  7^  j  <  n  ;  guar-Ti{o,a')  ^  rely-Tj{a,a')). 

Here,  o  is  the  conglomeration  of  global  and  local  variables  accessible  to  a  task.  Note  that  since 
i  ^  j,  z.  task  can  do  what  it  relies  on  other  tasks  not  to  do. 

The  main  operation  must  satisfy  the  precondition  of  each  task: 
pre-OP{o)  (Vi  ;  1  <  :  <  n  :  pre-T,{a)). 

This  obligation,  or  more  precisely  its  imprecision,  suggests  that  there  are  an  enormously  large 
number  of  proof  obligations  —  Jones  explicitly  identifies  only  some  of  them.  We  identify  the  others 
later,  as  a  criticism  of  Jones’  method. 

The  remaining  proof  obligations  refer  to  a  dynamic  invariant.  This  is  a  relational  predicate 
specifying  that  the  computation  being  performed  is  solving  the  problem.  A  dynamic  invariant  is 
comparable  to  the  loop  invariant  of  Hoare  Logic  fame.  For  example,  if  the  problem  is  to  find  the 
maximum  element  in  an  array,  the  dynamic  invariant  should  say  something  along  the  lines  of  “the 
candidate  solution  is  no  less  than  all  elements  examined  so  far”.  Clearly,  the  pre-condition  of  the 
main  operation  must  establish  the  dynamic  invariant: 
pre-OP{a)  dinv{a,o). 

This  corresponds  to  the  basis  in  an  induction  proof. 

Furthermore,  the  interference  expected  by  the  main  operation  must  not  violate  the  dynamic 
invariant: 

dinv{a,o')  A  rely-OP{a' ,o")  ^  dinv{a,a"). 

Since  the  tasks  implementing  the  main  operation  are  expected  to  contribute  to  the  solution, 
they  should  preserve  the  dynamic  invariant: 

dinv{o,o')  A  (3i  :  1  <  :  <  n  :  gxiar-Ti{a\o"))  =>  dinv{a,a"). 

Finally,  if  the  dynamic  invariant  has  survived  the  execution  of  each  task  and  each  task  has 
terminated  successfully,  the  main  operation  should  terminate  successfuUy: 

dinv{c,a')  A  (Vi :  1  <  i  <  n  ;  post-Ti{a,o'))  =>  post-OP(c,o'). 

Actually,  the  preceding  proof  obligation  does  not  mention  termination.  Therefore,  a  nonterminating 
task  needs  a  post-condition  of  true. 

In  order  to  abbreviate  specifications  and  simpbfy  proofs,  Jones  allows  access  restrictions  to 
be  attached  to  the  declaration  of  a  variable.  For  example,  a  variable  can  be  declared  as  read¬ 
only  within  a  task,  making  post-condition  and  rely-condition  clauses  specifying  this  form  of  access 
unnecessary.  This  is  a  good  example  of  Jones’  ohilosophy  of  rigor  versus  formality.  Unfortunately, 
he  does  not  provide  a  fist  of  allowable  abbreviations  —  perhaps  read-only  is  the  only  one. 
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2.7.3  Critical  Remarks 


Jones’  method  is  primarily  an  extension  of  his  sequential-program  development  method.  This 
sequential  method  utilizes  only  pre-conditions  and  post-conditions.  As  with  many  augmented 
approaches,  there  are  sharp  edges.  Some  of  them  are  discussed  here. 

While  useful  for  documenting  interference  assumptions  and  promises,  Jones’  method  appears 
to  be  deficient  concerning  task  synchronization.  For  example,  he  recognizes  that  deadlock  avoid¬ 
ance  requires  an  extension  to  his  method.  He  suggests  some  form  of  temporal  logic  or  a  location 
predicate.  Perhaps  a  location  predicate  can  be  simulated  by  auxiliary  variables,  as  is  done  to  con¬ 
trol  interference  when  developing  a  “proof  outline”  for  a  concurrent  program.  If  so,  no  extension 
is  necessary.  Unfortunately,  such  simulation  is  rather  awkward. 

Another  difficulty  is  deciding  where  to  put  (i.e.,  conjoin)  individual  specification  clauses.  A 
pre-condition  clause  can  be  confused  for  a  rely-condition  clause,  and  vice-versa;  a  post-condition 
clause  can  be  confused  for  a  guarantee- condition  clause,  and  vice  versa.  Moreover,  a  clause  often 
needs  to  be  in  both  confusable  conditions.  The  problem  seems  to  be  that  a  task’s  pre-condition  and 
rely-condition  are  independent  —  except  at  task  entry.  Likewise,  the  post-condition  and  guarantee- 
condition  are  independent  —  except  at  task  exit. 

Recall  the  claim  that  Jones  explicitly  identifies  only  some  proof  obligations;  we  elaborate 
this  claim  here.  In  his  examples,  Jones  gives  a  specification  for  each  task  or  function  —  no  finer 
granularity  is  mentioned.  In  fact,  however,  the  behavior  of  each  statement  in  a  program  needs  to  be 
specified  by  a  pre-condition,  post-condition,  rely-condition,  and  guarantee-condition  (or  defaults). 
This  is  similar  to  a  “proof  outline”,  where  an  assertion  is  placed  before  and  after  every  statement. 
Such  detail  allows  implementations  to  be  proven  correct,  but  the  universal  quantifiers  in  the  proof 
obligations  cause  the  amount  of  work  required  to  explode. 

A  related  criticism  concerns  a  higher-level  view  of  the  development  process.  Recall  that  a 
major  advantage  of  Jones’  method  is  that  correct-implementation  proofs  can  be  carried  out  between 
decomposition  steps,  rather  than  after  complete  decomposition.  Thus,  the  reader  is  perhaps  seduced 
by  the  suggested  development  sequence: 

{decompose,  prove}"_j 


resulting,  after  n  steps,  in  a  verified  solution.  Alas,  experience  suggests  the  more  alarming: 
^decompose,  prove-^^’^l  ^ 

where  the  function  /  grows  pretty  fast.  The  problem  is  that  interference  can  occur  between  op¬ 


erations  on  nonadjacent  levels  in  the  development  tree;  this  potential  interference  generates  proof 
obligations.  The  deeper  the  tree  gets,  the  more  obligations  there  are  at  each  step.  There  is,  perhaps. 


no  way  to  avoid  this  proof  explosion  when  verifying  concurrent  programs. 


2.8  Lamport 

2.8.1  Overview 

Lamport  has  done  a  great  deal  of  work  regarding  the  specification  of  concurrent  programs 
(OL82][Lam82][Lam86).  The  model  used  in  the  bulk  of  this  work  is  a  formal  proof  methodol¬ 
ogy  based  upon  temporal  logic.  Temporal  logic  may  be  used  to  describe  a  concurrent  program  at 
any  level  of  abstraction,  which  permits  hierarchical  specification  and  verification. 

Lamport’s  method  of  verifying  concurrent  programs  as  described  in  [Lam86]  consists  of  fac¬ 
toring  a  global  program  invariant  into  ‘pieces’  that  are  attached  to  control  points  in  the  program. 
Control  state  then  an  expLcit  part  of  the  invariant,  and  is  described  via  control  predicates.  Control 
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state  is  necessary  in  Lamport’s  method,  since  the  invariant  assertions  attached  to  one  process  may 
need  to  refer  to  the  control  state  of  other  processes.  The  Owicki-Gries  method  uses  dummy — or 
auxiliary — variables  rather  than  explicit  encoding  of  control  information.  An  extended  version 
of  the  Owicki-Gries  method  is  described,  which  may  be  used  to  prove  a  larger  class  of  program 
invariants. 

2.6.2  Technical  Discussion 

In  [OL82],  Owicki  and  Lamport  describe  a  method  whereby  liveness  properties  are  derived  using 
temporal  logic  and  proof  lattices.  Temporal  logic  is  a  method  of  specifying  assertions  about  future 
events.  Thus,  two  new  operators  are  added  to  propositional  calculus; 
op  P  is  true  from  now  on 
OP  P  will  be  true  at  some  time  hereafter 

A  third  piece  of  notation  is  also  useful:  the  assertion  P  ^  Q  is  true  iff  during  an  execution  of  a 
program  which  reaches  a  state  where  P  is  true,  Q  becomes  true  eventually.  This  notation  will  be 
useful  in  describing  proof  lattices. 

Proof  lattices  are  written  as  finite  directed  acyclic  graphs,  where  predicates  are  shown  as  nodes 
and  a  directed  arc  is  drawn  between  predicates  P,  Q  if  the  relation  P  Q  holds.  Each  lattice  has 
a  single  exit  node  and  a  single  entry  node.  Clearly,  if  a  proof  lattice  with  entry  point  P  and  exit 
point  Q  exists,  then  P  Q. 

A  simple  programming  language  is  introduced;  its  only  statements  are:  assignment,  while, 
cobegin,  and  variable  declaration.  The  semantics  of  the  program  consist  of  the  set  of  all  its  possible 
execution  sequences.  Execution  sequences  describe  a  series  of  program  states,  each  consisting  of 
a  value-assignment  to  each  program  variable  and  t  control  component.  The  control  component 
consists  of  a  set  of  atomic  actions  which  are  eligible  for  execution.  Concurrency  is  modeled  by  “a 
nondeterministic  interleaving  of  atomic  actions  from  the  various  processes  ...  almost  any  concurrent 
system  can  be  accurately  modeled  this  way  ...  any  safety  or  liveness  properties  proved  about  the 
model  will  be  true  of  the  system.”  An  additional  constraint  on  the  model  is  that  no  process  is 
‘infinitely  faster’  than  any  other,  which  provides  fairness;  additionally,  atomic  actions  are  assumed 
to  terminate. 

The  control  component  may  contain  three  different  assertions;  at  A,  in  A,  and  after  A  (A 
is  an  executable  program  statement).  These  assertions  mean:  control  is  at  the  program  point 
immediately  preceding  statement  A,  statement  A  is  being  executed,  control  is  at  the  program  point 
immediately  following  A. 

Livendss  properties  are  statements  about  control  flow;  thus,  they  may  be  derived  from  program 
invariants  which  include  control  flow  information.  Owicki  and  Lamport  provide  the  following  rules 
for  this  purpose: 

Control  Flow  Rule  1  (Concatenation)  For  the  statement  S;T 
at  S  ^  after  5  ,  at  T  after  T 

at  S  after  T 

Control  Flow  Rule  2  (COBEGIN)  For  the  statement  ciCOBEGIN  S  ||  T  COEND 
at  S  after  S  ,  at  T  after  T 

at  c~^  after  c 

Control  Flow  Rule  3  (Single  Exit)  For  any  statement  S: 
in  S  =>  (Din  S  or  Oafter  S  ) 

Control  Flow  Rule  4  (Atomic  Statement)  For  any  atomic  statement  <  S  >: 
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{P}  <  5  >  {<?}.0(at  <S>=>  P) 

<S>'^  {after  <  S  > /^Q) 

Control  Flow  Rule  5  (General  Statement)  For  any  statement  S: 

{P}5{<?},  0(171  5  =>  P),*n  5  after  S 
in  S  ^  {after  S  A  Q) 

Control  Flow  Rule  6  (while  TEST)  For  the  statement  w:  while  <  B  >  do  S  od 
at  w  {{at  S  A  R)  or  {after  w  A  ~'B)) 

Control  Flow  Rule  7  (while  EXIT)  For  the  statement  w:  while  <  B  >  do  S  od 
{at  w  andO{at  w  =»  R))  5 

(ot  w  an(20(at  to  =>  •^B))after  to 

These  rules  may  be  used  to  create  a  graphical  lattice  proof  of  liveness  properties.  The  paper 
describes  a  liveness  proof  of  the  standard  mutual  exclusion  problem,  using  the  following  invariant: 

(ot  S  ondOO-'tn  CS^)  =>  {after  NCi'^  in  CSi) 
where  CSi  is  the  critical  section  of  process  t  and  NCi  is  the  non-critical  section  of  process  i.  This 
formulation  states  that  process  2  is  guaranteed  access  to  its  critical  section  if  process  1  remains  in  its 
noncritical  section.  (Unfortunately,  this  logic  cannot  be  used  to  express  the  more  useful  statement 
that  "within  a  reasonable  amount  of  time”  each  process  will  be  permitted  access  to  its  critical 
section;  it  is  only  possible  to  state  that  ‘always’  a  property  will  hold  or  ‘eventually’  a  property 
will  hold.)  The  proof  consists  of  starting  with  the  contradictory  expression — that  process  2  does 
not  eventually  get  access  to  the  critical  section — and  generating  a  proof  lattice  which  leads  to  a 
contradiction. 

2.8.3  Critical  Remarks 

Temporal  logic  is  a  useful  tool  for  reasoning  about  liveness  properties  of  concurrent  programs,  since 
it  permits  statements  about  future  events.  Lamport’s  model  of  temporal  logic  relies  upon  discrete 
events,  which  may  reduce  the  model’s  usability  for  systems  which  cannot  be  represented  this  way. 
The  use  of  a  proof  lattice  greatly  simplifies  liveness  proofs.  However,  this  version  of  temporal  logic 
has  the  usual  disadvantage  of  not  being  expressive  enough  to  place  bounds  on  the  time  which  it 
will  take  before  an  event  will  occur. 

It  is  Lamport’s  contention  that  using  dummy  variables  to  represent  control  state  limits  their 
utility.  He  describes  a  strengthened  version  of  the  Owicki-Gries  method  that  uses  explicit  control 
predicates,  permitting  a  larger  class  of  invariants  to  be  proven. 

% 

2.9  Misra  and  Chandy 

2.9.1  Overview 

In  (MC81],  the  authors  present  a  proof  techxiique  for  networks  of  processes  which  communicate 
via  messages.  The  basic  notation  is  similar  to  CSP  {Hoa78]  but  uses  explicit  channel  naming 
rather  than  explicit  process  naming  for  message  passing.  One  channel  connects  exactly  one  pair  of 
processes.  Channels  are  directional.  A  channel  is  said  to  be  incident  on  the  processes  it  connects. 

Processes  are  specified  by  a  pair  of  assertions  r  and  s,  one  corresponding  to  a  precondition 
and  the  other  to  a  postcondition.  For  a  process  h,  r|fi|s  specifies  that  assertion  s  holds  initially, 
if  r  holds  prior  to  a  message  transmission  then  “s  holds  at  all  times  prior  to  and  immediately 
following  that  message  transmission.”  Message  transmission  refers  to  the  sending  or  the  receiving 
of  a  message  by  process  h.  Assertions  are  on  traces  (described  later). 
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Processes  are  defined  to  be  either  a  sequential  processes  or  a  network  of  processes.  Sequential 
processes  contain  commands  for  message  transmission.  Networks  consist  of  processes  and  their 
channels.  Channels  may  exist  between  processes  in  separate  networks:  for  example,  if  a  channel  is 
directed  from  process  h,  to  process  hj  and  is  within  network  B  but  hj  is  external  to  B,  then 
the  channel  is  said  to  be  incident  on  B  and  directed  away  from  B .  If  both  processes  are  within  B 
then  the  channel  is  internal  to  B. 

Misra  and  Chandy  also  make  use  of  traces.  An  external  trace  of  a  process  h  at  a  particular 
point  during  computation  is  a  sequence  of  tuples  <  (Ci,  ti), . . ., (Cn,  Vn)  >  where  the  message 
sent/received  by  h  is  along  channel  Ci  incident  on  h,  and  the  message  has  value  u,.  An  internal  trace 
of  a  process  h  is  also  a  sequence  of  tuples  <  {Ci,ui), . .  ■,(Cn,^n)  >,  where  in  that  computation  the 
message  transmitted  on  all  channels  incident  on  or  internal  to  h  is  transmitted  along  channel  C, 
with  value  v,.  All  traces  are  initially  null  sequences.  For  proof  purposes,  traces  may  be  considered 
auxiliary  variables. 

Notation  for  sequences 


z 

Length  of  Z 

Zi«Z2 

Zi  is  an  initial  substring  of  Z2 

Zi  =  22 

Z\,Z2  are  identical  sequences 

2i|22 

Sequence  obtained  by  appending  ^2  to  21 

<ei, . ,  .,c„> 

Sequence  having  elements  e,  in  the  given  order. 

Two  inference  rules  and  a  theorem  are  used  extensively  in  proving  the  examples  given  in 
[MC81].  They  are: 

Rule  1  (Network  Composition)  Deduce  the  internal  specification  of  a  network  B  from  the  ex¬ 
ternal  specifications  of  its  component  processes  h,: 
r.|/i.|s.,Vt 

A.  A.  5. 

Rule  2  (Inductive  Consequence)  Implication  on  precondition  and  implication  on  postcondi¬ 
tion. 

{sf\r)  =>  t\  T'\h]s 
r\h]s 

r[/t]s',  s'  =»  s 
r[/i]j 

Theorem  1  (Hierarchy)  Use  the  external  specifications  of  network  B ’s  component  processes  h, 
to  produce  B ’s  external  specification. 

Vi,  (5  A  ^o)  =^'  -S’  =>  Sq 

Ro\B\So 

where  Rq,  Sq  are  assertions  on  the  external  trace  of  B ,  and  R,  S  denote  A,  A.  •St 
2.9.2  Technical  Discussion 

The  individual  processes/networks  must  be  specified  as  described  above  (i.e.,  for  a  process,  give  the 
r|/i|5  assertions;  for  a  network,  additionally  provide  channel  descriptions.  Note  that  no  network¬ 
wide  or  global  variables  may  be  used  in  the  specifications,  though  individual  processes  may  use 
their  particular  trace  as  an  auxiliary  variable.  For  example,  a  buffer  process  h  might  include  the 
assertion 

true\h\Zout2.^,n 
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which  ' St Ates  th»t  the  sequence  of  messages  output  by  a  buffer  is  an  initial  subsequence  of  the 
sequence  of  messages  it  receives. 

It  must  be  shown  that  r|h|s  holds  for  each  process /network. 

•  Sequential  Process 

1.  Assert  that  the  trace  of  A  is  empty. 

2.  Show  that  *  holds  initially. 

3.  Assert  r  before  and  after  each  message  transmission  command. 

4.  Annotate  h. 

5.  Por  each  message  transmission  M  show  {  pte(i/)  }  if  {s} 

•  Networks 

1.  Component  processes  must  be  shown  to  fulfill  r|A{s. 

2.  The  network  assertion  l^o  mut  be  shown,  where  J2o«  Sq  are  assertions  on  the 
external  trace  of  E.  This  is  done  using  the  Theorem  of  Hierarchy. 

2.9.S  Critical  Remarks 

Misra  and  Chandy’s  system  cannot  be  used  to  prove  temporal  properties  directly  (e.g.,  eventual 
deadlock,  eventual  termination).  Additionally,  [BarSS]  point  out  that  Misra  and  Chandy's  reliance 
on  traces  make  it  difficult  to  describe  ffioite  input  sequences,  since  it  introduces  a  great  deal  of 
complication  in  the  trace  assertions. 


3  System  Survey 

3.1  Overview 

Tixis  section  of  the  report  presents  the  specific  details  of  the  systems  survey  that  we  have  conducted. 
As  with  the  methodologies,  the  systems  survey  is  organized  by  the  "short  list”  presented  in  Section 
1.  This  list  contains  six  of  the  most  significant  and  representative  systems  for  software  specification 
and  verification:  Affirm,  EHDM,  FAS£,  HOL,  Larch,  and  0BJ3.  In  addition  to  these  six  systems, 
four  other  systems  that  did  not  make  our  short  list  are  reviewed.  These  four  systems  are: 

•  Eves  -  a  verification  system  with  emphasis  on  verification  of  security 

•  Gypsy  -  an  early  system  for  the  specification  and  verification  of  concurrent  programs,  in¬ 
cluding  support  for  code-level  verification 

•  Nuprl  -  a  verification  system  related  to  HOL  but  based  on  an  alternate  form  of  logic 

•  VDM  -  a  foundational  system  for  state-based  specification,  with  some  strong  similarities  to 
EHDM 

We  have  included  these  additional  reviews  since  the  systems  are  significant,  highly  visible,  and  have 
some  important  relationships  to  the  systems  on  our  short  list.  However,  in  terms  of  the  systems 
that  shape  the  design  of  the  prototype  workbench,  the  six  short-list  systems  have  all  of  the  features 
and  concepts  that  we  need. 

Following  the  detailed  system  reviews,  our  system  survey  concludes  with  a  subsection  that 
compares  the  results  of  a  detailed  verification  task  carried  out  on  the  three  systems  with  which  we 
have  the  most  direct  experience  -  Affirm,  0BJ3,  and  HOL.  This  more  detailed  comparison  further 
supports  our  general  conclusion  that  no  single  system  has  all  the  features  necessary  to  specify 
and  verify  concurrent  software  in  a  natural  and  convenient  manner.  Hence,  our  workbench  design 
embodies  features  from  several  existing  systems. 

3.2  Summary  Comparison  Table 

Table  2  summarizes  the  results  of  our  survey  of  existing,  reasonably  mature  computer-based  systems 
for  specification  and  verification.  Listed  in  the  Table  are  those  systems  that  made  our  "short  list.” 
For  the  most  part,  these  systems  support  specification  and  verification  of  sequential  programs,  with 
a  few  features  for  the  support  of  concurrency.  An  essential  goal  of  our  research  is  to  meld  features 
from  the  methodologies  of  Table  1  with  the  mature  systems  of  Table  2,  producing  a  usable  tool. 

As  with  the  methodologies  comparison  table,  key  system  features  are  listed  leftmost  table 
column,  and  the  reviewed  systems  listed  along  the  top  row.  The  system  features  are  organized  into 
five  major  categories.  Each  of  these  categories  is  described  briefly  below.  In  the  subsections  which 
follow  the  tables,  detailed  reviews  of  the  summarised  work  are  presented. 

In  IVble  2,  the  features  under  the  category  "Execution  Support"  refer  to  the  major  models 
of  execution;  the  primary  dichotomy  in  execution  model  is  the  whether  the  system  supports  fully 
functional  execution  (i.e.,  no  side  effects)  versus  execution  with  state  memory  (i.e.,  side  effects  are 
allowed).  The  "Forms  of  Logic"  category  includes  the  same  entries  as  in  Thble  1  in  Section  2  of 
the  report.  The  "Checking”  category  indicates  whether  the  system  performs  completeness  and/or 
consistency  checks  of  specifications.  "Verification  Support”  includes  a  number  of  features  useful  in 
a  computer-aided  verification  systems.  Finally,  the  category  of  "Qualitative  Measures”  lists  general 
features  of  the  systems. 
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Affirm 

EASE 

EHDM 

HOL 

Larch 

0BJ3 

Execution  Support: 

Rewriting 

X 

X 

X 

X 

X 

X 

Functional  Evaluation 

X 

X 

X 

X 

State  Memory 

X 

X 

Interpretation 

X 

X 

X 

X 

X 

X 

Compilation 

X 

Error  Handling 

fair 

good 

good 

good 

fair 

Linkage  to  Low-Level  PL 

Paacal 

Litp 

Pascal 

CLU 

Lisp 

Predicate  Calculus 

X 

X 

msm 

Propositional  Logic 

Quantification 

X 

X 

X 

X 

X 

Temporal  Logic 

Higher-Order  Logic 

X 

Bpyer-Moore 

Eqnational 

X 

X 

X 

X[l] 

X 

X 

Hoare  Logic 

X 

X 

(2) 

X 

Checking: 

X 

X 

X 

X 

X 

X 

X 

X 

X 

Varifieation  Support: 


Hewriting 

X 

X 

X  X 

X 

X 

Ikctics 

Induction 

Decision  Procedure 
Proof  Management 

Test  Generation 

X 

X 

some 

X 

X 

X 

some  some 

X 

Top-Down  Support 

Ease  of  Use: 

X 

X 

X 

X 

X 

X 

Specification 

good 

good 

good 

fair 

good 

good 

Verification 

good 

N/A 

good 

good+ 

good 

poor 

Level  of  Support 

none 

good 

good 

good 

fair 

good 

Level  of  CcmpleteneM 

good 

good- 

good 

LIIU 

Table  2.  Systems  Comparisons 


Notes: 

1.  Ai  deKribcd  bclov,  ec  havt  anplcaieatcd  tome  cctcaaew  within  the  HOL  eyetem  to  rapport  a  form 

of  oquntionnl  lofic,  and  we  are  reaearch  in  thie  area. 

2.  la  pikers  on  the  Larch  eyetem,  the  authore  deeezibe  the  interfrae  from  the  Larch  eqnational  logic  to 
predicate  logic,  but  it  ia  unclear  from  ayatem  deacripUna  if  the  implemented  ayatem  rapporta  machine- 
baaed  predicate  logic. 
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3.3  Affirm 

3.3.1  Overview 

This  section  presents  &  overview  of  the  capabilities  of  the  Affirm  system  from  ISI  [TESl]  as  a  tool 
for  the  development  of  abstract  specifications  and  their  verification.  Although  a  later  version  exists, 
Affirm-85  from  General  Electric  Company  [Kem86],  this  review  covers  the  version  developed  at  ISI. 

Affirm  is  an  interactive  system  for  the  formal  specification  and  verification  of  abstract  data 
t}rpes  (ADTs)  and  programs.  It  uses  an  algebraic  specification  language  very  similar  to  that  pre¬ 
sented  in  [GHM78].  Using  this  language  the  user  can  hierarchically  define  ADTs  and  a  set  of 
equational  rewrite  rules  for  them.  For  each  ADT  the  user  need  not  completely  define  the  rewrite 
rules  of  the  operations  but  need  only  define  the  type  signatures.  This  allows  the  user  to  incremen¬ 
tally  develop  the  specification,  leaving  implementation  decisions  untU  a  later  date. 

While  the  specification  is  being  developed,  the  user  can  apply  some  tools  provided  by  Affirm 
to  test  the  specification.  Affirm  will  automatically  check  these  rules  for  consistency  using  the 
incremental  Knuth-Bendix  algorithm.  It  also  provides  methods  for  testing  completeness  using  the 
Guttag-Homing  recognisable  sufficient  completeness  test  [GH78].  And,  it  allows  testing  of  simple 
cases  by  actually  executing  the  specifications. 

Affirm  also  supports  a  PASCAL-like  statement  language  for  the  algorithmic  implementation 
of  operations  in  the  ADTs.  This  language  diffiers  from  PASCAL  by  requiring  all  data  types,  and 
operations  performed  on  them,  be  defined  as  ADTs  in  Affirm.  It  also  has  a  few  additional  constructs 
that  allow  the  user  to  add  assertions  about  these  types  throughout  the  code.  Using  these  assertions. 
Affirm  can  automatically  generate  verification  conditions  (propositions)  ing  the  inductive  assertion 
method  [Flo67]  or  proving  the  code  satisfies  the  assertions. 

Using  the  algebraic  specification  language,  the  user  can  also  generate  equational  propositions. 
Once  the  system  has  propositions,  either  user  generated  or  as  verification  conditions,  the  user  can 
use  the  underlying  logic,  based  on  propositional  calculus,  along  with  instantiation,  case  analysis, 
skolemization,  normalization  and  unification,  to  prove  these.  The  structure  of  these  proofs  in  the 
system  is  maintained  as  a  directed  acyclic  graph  with  subgraphs  corresponding  to  the  proofs  of 
the  propositions.  The  user  can  change  the  graph  by  adding,  deleting  or  modifying  nodes,  with 
the  ultimate  goal  of  transforming  the  propositions,  by  rewrite  rules,  to  the  constant  TRUE.  If  this 
transformation  fails.  Affirm  will  try  to  inform  the  user  why  it  failed  and  let  the  user  correct  the 
proposition. 

3.3.2  Execution  and  Rapid  Prototype  Support 

As  stated  above,  since  Afiirm  is  a  rewrite  system,  any  of  the  rules  can  be  executed.  The  user  can 
simply  type  the  keyword  aval  followed  by  the  expression  to  evaluate,  and  Affirm  wiU  determine 
the  result. 

This  evaluation  method,  and  the  ability  to  develop  partial  specifications  along  with  hierarchical 
development,  make  Affirm  ideal  as  a  rapid  prototyping  system.  The  user,  when  devdoping  a  system 
can  mix  specifications  of  interfaces  that  have  yet  to  be  implemented,  with  actual  Pascal-like  code. 
At  all  levels  of  development  the  user  can  define  partial  operations  and  test  to  make  sure  they  satisfy 
the  requirements.  If  they  don’t  satisfy  the  requirements  they  can  be  modified  immediately  while 
Affirm  keeps  track  of  all  the  proof  obligations  and  consequences  of  the  change. 
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S.3.S  Abstraction  Mechanisms 

To  demonstrate  the  Affirm  abstraction  Mechanisms  we  give  a  sample  specification.  The  following 
is  the  part  of  the  Affirm  version  of  the  abstract  specihcation  of  the  Object  ADT  for  the  Low 
Water<Mark  System  as  given  originally  in  [Kem86]: 

type  Object; 

{  ee*  Oeelaratioas  } 

meeds  types  IleaType,  SecnrityLevel; 

declare  x.xliObject; 
declare  e:CleaType; 
declare  s, si: SecnrityLevel; 

{  •••  Syntax  of  eperatiens  •••  } 

iaterfaces  Vrite(e.x,s) ,  Eeeet(z.s).lBitial:Object; 
interface  ObjLeveKz)  :  SecnrityLevel; 
interface  Kead(z.a)  :  ZleaType; 
interface  Objectlndnctioa(z) : Boolean; 

{  •••  Seaantics  •••  } 
axiOBS 

lead(Vrite(e,s,sl).s}  aa 
if  si  <a  ObjLeveKx) 
then  if  si  *•  s  then  e  else  loll 
else  Bead(z,s), 

Bead(Beeet(z,sl),s)  ■« 
if  si  <a  ObjLeveKz) 
then  lull 
else  BeadCz.s), 

Bead(Zaitial,o)  ••  loll; 

define  xazl  •• 

(Bead(z,syahi)  •  Bead(zl,syshi)  and 
ObjLeveKz)  ■  ObjLeveKzl)) ; 

aeheaa 

ObjeetZadactienCz)  a« 
cases (Irep(Xnitial) , 

all  xl.e,s(Xl(zl)  imp  Prep(Vrite(e.sl.s))). 
all  xl,s  (ZKxl)  iap  Prep(Beset(xl,s}))}: 

and  {Object}; 

type  BleaType; 

{  aaa  Oeclaratioaa  •••  } 

declare  reflezive.dnaayiEleBType; 
interface  Inll  :  QeaType; 
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■{  •••  Swuntics  •••  } 

aziea  rcflaziv*  ■  rcllaziva  >  «  TRUE: 

•ad  {EIuiTjpa}; 

The  declaration  section  defines  needed  (i.e.,  imported  objects)  and  variables  used  in  the  axioms. 
Here  for  the  type  Object  we  use  ElemType  and  SecurityLevel  ADTs.  This  mechanism  allows  the 
user  to  hierarchically  define  ADTs,  where  a  lower  level  ADT  may  not  be  fully  specified.  The 
ElemType  ADR  is  a  good  example  of  an  ADT  which  has  declarations  but  no  semantics  for  the 
NULL  operation.  The  syntax  section  defines  the  interface  to  each  of  the  ADT’s  Operations. 

In  the  Object  ADT  there  are  several  operations,  to  permit  the  user  to  Read,  Write  and  Reset 
the  Object,  and  to  determine  the  security  level  of  the  opject  or  initialize  a  new  object.  The  semantics 
section  defines  the  meaning  of  the  ADT  in  terms  of  algebraic  axioms  about  its  operations.  In  AfErm, 
the  azioBs  are  specified  nsing  either  the  kejrword  azioB,  informing  the  system  to  automatically 
apply  an  axiom  whenever  applicable  in  the  course  of  a  reduction,  or  the  keyword  define,  informing 
the  system  that  the  user  will  specifically  invoke  all  applications  manually.  This  permits  the  user 
to  control  the  flow  of  a  proof  development  at  the  level  desired.  Affirm  also  allows  the  specification 
of  BChaaas  for  user  defined  proof  arguments. 

3.5.4  Forms  of  Logic  Supported 

The  Affirm  system  support  the  algebraic  specification  language  of  Guttag,  Horowitz  and  Musset. 
Any  propositions  in  the  specification  are  simply  Bolean- Valued  expressions  of  the  form 
nllzi , . . . ,  *„(someyi , ....  ...,  »».•••.  »m ))) 

where  all  and  some  are  universal  and  existential  quantifiers. 

In  Affirm,  all  logical  expressions  are  translated  into  a  simplified  internal  IF-THEN-ELSE  form 
and  skolemized. 

Also  supplied  in  the  system  is  an  operator  similar  to  the  weakest  liberal  precondition  (Dij76] 
to  generate  verification  conditions  for  the  Pascal-like  language  code  segments. 

5.5.5  Verification  and  Theorem  Proving  Support 

The  Affirm  system  also  supports  an  interactive  proof  development  environment.  This  is  neither  a 
proof  checker  nor  a  proof  finder. 

Using  the  rewrite  rules  of  the  data  types  along  with  the  rules  of  propositional  logic,  this 
evironment  is  used  to  "simplify'*  the  current  proposition  down  to  the  logi^  constant  TRUE. 

The  environment  supplies  some  built  in  functions  to  allow  the  user  to  invoke  definitions,  apply 
nnproven  lemmas,  split  the  proposition  into  subgoals,  and  cmplc^  data  type  Induction  schemas 
that  have  been  defined  by  the  user. 

To  manipulate  the  proof,  the  system  maintains  the  internal  tree  structure  of  the  proof  and 
allows  the  user  to  traverse  it  at  any  time  to  prove  a  current  leaf  or  retry  an  «Mr»«tiTi£r  node. 

5.5.6  Specification  Checking  -  Completeness  smd  Soundness 

Affirm  automatically  checks  for  axiom  inconsistencies  and  applies  an  incremental  Knuth-Bendix 
convergence  process  [KB70]  to  guarantee  that  all  axioms  maintain  the  Church-Rosser  unique  ter¬ 
mination  property.  The  user  can  also  apply  a  completeness  test  to  ensure  that  the  axiom  set  is 
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1 

I  siiffidently  complete  using  the  algorithm  presented  in  {Gut75]  and  [GH78}.  This  test  also  catego- 

’  rises  the  operations  into  the  constructors,  modifiers,  and  selectors,  which  information  can  be  useful 

in  other  aspects  of  ADT  verification. 

^  S.S.7  Formal  system  Buis  -  Completeness,  Consistency  and  Soundness 

I  As  mentioned  before  the  system  will  check  all  specifications  for  consistency  and  allows  the  user  to 

determine  sufficeient  completeness.  Based  on  the  nndttlying  logic  of  rewrite  rules  and  the  built  in 
aadomatization  of  integers  and  booleans  the  system  seems  complete. 

I  Qualitative  Measures 

The  system  is  very  usefol  and  easy  to  manipulate  the  proofs  and  specifications  of  the  system.  It 
I  does  not  support  any  built  in  induction  methodology  other  than  user  defined  schemas.  It  also 

does  not  support  higher  order  lope  although  it  gives  a  large  amount  of  useful  utilities  and  built  in 
^  techniques  for  the  logic  it  does  support. 

S.S.9  An  Example 

;  The  foQowing  is  the  Affirm  version  of  the  abstract  specification  of  the  Low  Water>Mark  ^vstem  as 

given  originally  in  [Kem86]; 

type  SeeurityLevel ; 

{  •••  Oeelaratloas  •••  } 

declare  el, ell: SeeurityLevel; 

{  •••  Syntax  o1  operations  •••  } 
intertaees  el  sll,  el  >■  ell  :  Boolean; 
iatortace  syshi:  SeeurityLevel; 

{  •••  Seaantice  •••  } 
azioas 

si  <>  si  ■>  TIUE. 
si  <■  syshi  ■■  nUE; 

azioa 

si  >•  sll  ■■  sll  <■  si; 

ead  {SoeurityLovol}; 

typo  neaType; 

{  eee  Oeelaratloas  eee  } 
declare  reflezive.dauy:  EloaType; 

{  eee  Seaaatics  •••  } 

laterfaee  Bull  :  EleaType; 

azioa  reflexive  •  reflexive  e  s  T&UE; 
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•Bd  {ElaaTyp*}; 
t7p«  Object; 

{  •••  OecImratioB*  •••  } 

needs  type*  EleaType,  SecnrityLevel ; 

declare  x.zlrObject; 
declare  e:ElaaType: 
declare  a, al: SecnrityLevel; 

{  *•*  Syataz  of  operatioas  eee  } 

iaterlaeas  VriteCe.z.s) ,  fteset (z. a). Zaitial: Object; 

iatarlaee  ObjLeveKz)  :  SecnrityLevel; 

iaterface  &ead(z,s)  :  EleaType; 

iatarface  ObjectZadnetioaCz) :Booleaa; 

{  Seaaatics  } 

azioaa 

ObjLeval(Vrite(e,z,s)) 
if  a  <a  ObjLevel(z) 
tbea  a 

elae  ObjLevel(z), 

ObjLeveKRaaetCz.a))  •- 
is  a  <a  ObjLevel(z) 
tbea  ayabi 
elae  ObjLevel(z), 

ObjLeveldaitial)  m  ayabi; 

azioaa 

tead(Hrite(e,z,al) ,a)  •* 
is  al  <«  ObjLeveKz) 
tbea  if  si  <«  a 
tbea  e 
else  Inll 

else  beadCz.s), 

Eead(beset(z,sl),s)  *« 
is  al  <*  ObjLeveKz) 
tbea  Inll 
elae  &ead(z,s), 
beadCZaitial.s)  ■■  Inll; 

defiaa  z>zl  ■■ 

(bead(z, ayabi)  ■  lead(zl. ayabi)  and 
ObjLeveKz)  ■  ObjLeveKzl}) ; 

acbeaa 

ObjeetZBdnetiea(z)  ■■ 
eaaea(Prop(Zaitial) , 

all  zl,e,e(IH(zl)  iap  Prop(Write(e,zl,a))) , 
all  zl,a  (ZBCzI)  iap  Prop(Reaet(zl.a))}); 
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•ad  {Object}; 


priat  proof; 

thoorea  StarProsonrod.  *(•  <•  ObjLavoKz))  lap  Vrit«(o,  z,  a)  •  z; 

proof  tr««: 

73:!  StarPrasarvad 
iBToka  ■ 

73:  11  easaa 

73:->  (proraa!) 


•7  U:  priat  proof; 

tkaeraa  SSCpraaarvad.  *(ObjLaval(z)  <■  a)  lap  Eaad(z.  a)  ■  loll; 


proof  traa: 

61 : l-PSSCpraaarrad 


ai^loy  ObjactZadactloB(z) 

/•  Bare  ea  aaploy  user  defined 

Initial: 

/•  indaetion  aekana 

ianadiata 

61: 

Vrita: 

/•  For  tka  Vrita  caaa  apply  caaa 

3  eaaas 

/•  analyaia  tkaa  invoke  Zndnetioa 

63: 

4  invoke  IH 

/•  kypotkaaia.  iff in  tkan  can 

64: 

S  pat  a ' *  ■  a  aaarck 

/•  'aaarck'  for  tka  proper 

64: 

(proven!) 

/•  instantiation 

66: 

laaat:  SSCpraaarvad 

/•  Sana  for  Bead 

3  easaa 

67: 

7  invoke  IB 

66: 

8  pat  a"  *  s  aaarck 

66: 

(proven ! ) 

/*  lavoka  tka  azioa 
/•  dad  tkaa  apply  caaa  aaalyaia 


S.S.IO  Critical  Remarka 

In  a  angle  enrironment  Affirm  permits  the  nser  to  algebracally  tpedfy  ADTi,  test  them  for 
consistency,  completeness  and  execute  test  cases,  prove  propositions  by  transforming  them  using  the 
underlying  logic  and  rewrite  rules,  and  verify  PASCAL-like  programs  using  the  inductive  assertion 
method. 

Affirm  lacks  any  form  of  parameterized  typing.  The  current  version  of  the  system  uses  the 
‘Hext^tor”  method  of  parameterization.  In  this  particular  example,  the  lack  of  parameterization 
was  not  a  problem.  However,  in  examples  with  an  ADT  applied  to  several  different  types  (e.g.,  bits, 
bytes,  words,  and  n-bit  values  etc.)  the  user  would  have  to  enter  the  specification  for  eadi  separately. 
If  these  spedfications  had  intetfaces  with  identical  names,  the  user  would  then  be  prompted  for 
the  fype  signature  at  evoy  use  of  each  unqualified  inter&ce.  Furthermore,  the  verification  of  each 
instance  of  the  AST  would  need  to  be  separately  verified. 
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3.4  Enhanced  HDM 
3.4.1  Overview 

This  section  is  a  brief  introduction  to  Enhanced  HDM  (Hierarchical  Development  Method¬ 
ology)*  interactive  system  for  the  composition  and  analysis  of  formal  specifications  and 
programs|vHR90][Riis90].  It  has  been  under  continnons  development  at  SRI  since  1983;  the  Na¬ 
tional  Computer  Security  Center  and  NASA-Langley  Research  Center  have  been  its  principal  spon¬ 
sors.  EHDM  shares  some  concepts  with  SRI’s  previous  methodology,  HDM  (a.k.a.  old  HDM),  for 
example  the  capability  of  expressing  specifications  for  operations  (as  model-based  specifications) 
and  a  flow  analyzer  that  determines  if  a  specification  is  consistent  with  a  model  of  multilevel 
security.  However,  Enhanced  HDM  is  more  expressive  and  has  substantially  more  proof  support. 

The  unique  features  of  Enhanced  EDM  are  the  expressiveness  of  its  specification  language 
(Revised  Special),  certain  aspects  of  the  approach  to  mechanized  theorem  proving,  its  unique 
approach  to  permit  the  reasoning  about  expressions  that  intermix  declarative  specifications  and 
imperative  statements,  and  the  support  for  verifying  security  properties  of  a  specification. 

Revised  Special  encourages  a  style  of  specification  whereby  a  user  can  proceed  from  abstract 
specifications  through  more  detailed  specifications,  the  process  terminating  with  programs  written 
in  a  small  but  unimplemented  subset  of  Pascal.  Each  step  in  the  process  entails  the  formulation 
of  decisions  that  are  verified  with  respect  to  previous  decisions.  EHDM  does  not  provide  support 
for  the  verification  of  executable  and  optimized  programs.  A  system  cannot  be  said  to  be  verified 
unless  executable  code  is  verified.  However,  substantial  assurance  about  a  system  is  obtained  by 
verifying  specifications,  and  abstract  algorithms  that  are  easily  converted  into  prograims.  EHDM 
encourages  a  user  to  verify  properties  of  a  system’s  abstract  specificatioiu  and  of  implementation 
decisions  described  as  abstract  algorithms  in  a  language  that  has  many  features  of  Pascal  and  Ada. 

The  justification  for  a  system  like  EHDM  is  empirical  evidence  that  most  of  the  undetected 
(and  difiicult  to  fix)  errors  in  delivered  systems  occur  in  what  is  perceived  as  the  design  stages  of 
development.  Using  EHDM,  the  design  of  a  system  can  be  expressed  as  specifications  and  abstract 
algorithms. 

Among  the  unique  features  of  Revised  Special  are: 

•  Parameterizable  modules,  through  which  generic  modules  can  be  specified,  verified  and  ap¬ 
propriately  used. 

•  Support  for  second  order  predicate  calculus,  which,  among  other  things,  allows  the  user  to 
define  and  reason  about  induction  schema. 

•  Support  for  program  operations  as  first-class  objects,  which  allows  the  user  to  declare,  specify, 
implement  and  verify  operations  at  convexuent  points  in  the  development  of  a  system. 

The  goal  for  the  EHDM  theorem  prover  was  to  produce  a  fast  and  predictable  response.  To  that 
end,  EHDM’s  theorem  prover  is  based  on  a  collection  of  decision  procures.  A  decision  procedure 
determine  whether  a  predicate  within  its  domain  of  decidability  is  true  or  false.  EHDM  includes 
decision  procedures  for  propositional  logic,  equality  over  nninterpreted  functions,  and  Presburger 
arithmetic  (essentially  linear  arithmetic).  However,  the  lope  of  Revised  Special  is  much  more  pow- 
ezful  (i.e.,  first  and  second  order  predicate  calculus),  and  is  essential  to  express  properties  of  complex 
software  systems.  In  order  to  prepare  a  formula  of  Revised  Special  for  proof  by  the  theorem  prover, 
the  user  can  exercise  combinations  of  the  following  options:  (1)  Cite  (other  formulas)  premises 
to  be  used  in  the  proof,  (2)  Provide  substitutions  for  certain  quantified  variables,  and  (3)  Accept 
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the  rabstitutioas  generated  by  EHDM's  aniiication  and  resolution  packages.  This  preprocessing 
will  transform  the  Revised  Special  formulas  into  formulas  in  the  domain  of  the  theorem  prover's 
decision  procedures. 

EHDM  includes  support  for  the  verification  of  system  security  properties,  mainly  attempting  to 
identify  covert  channels  that  involve  the  transfer  of  information  through  the  operating  system  state. 
The  MLS  tool  mechanizes  the  verification  of  Revised  Special  specifications,  restricted  to  a  particular 
style,  with  respect  to  an  information  flow  model  of  security.  The  purpose  is  to  demonstrate  that 
according  to  the  specifications  there  is  no  flow  of  information  from  a  secure  object  to  a  secure 
object  of  a  lower  level.^  It  should  be  noted  that  use  of  the  MLS  tool  cannot  guarantee  the  absolute 
security  of  a  system.  In  particular,  the  tool  does  not  establish  the  correctness  of  executable  code; 
furthermore,  the  specifications  it  analytes  are  relatively  abstract,  precluding  any  representation 
decisions  that  would  allow  the  multiplexing  of  an  object  among  different  security  levels.  However, 
the  tool  can  detect  some  insecurities  that  originate  early  in  the  design  process,  often  subtle  ones 
that  would  be  difficult  to  reveal  by  inspection  of  executable  code. 

A  rugged  version  of  the  Enhanced  HDM  system  has  been  completed  and  documented,  and  is 
available. 

The  remaining  sections  of  this  overview  describe: 

•  A  scenario  for  tue  of  the  Enhanced  HDM  system. 

•  The  Revised  Special  specification  language. 

•  The  Pascal/Ada  subset  that  constitutes  the  language  for  expressing  verified  programs. 

•  A  hierarchical  development. 

•  The  theorem  prover  and  how  it  is  used  to  verify  properties  of  specifications,  operations,  and 
abstract  programs. 

•  The  MLS  tool. 

•  The  implementation  of  Enhanced  HDM. 

•  A  summary  of  av^able  documentation. 

•  A  description  of  SRl’s  research  in  verification  and  software  methodology  that  led  to  Enhanced 
HDM.  Applications  of  Enhanced  HDM  and  its  predecessors  are  also  summarized. 

•  Strengths  and  weaknesses  of  the  current  system. 

S.4.2  The  Enhanced  HDM  Methodology 

As  conceived  by  Floyd  in  the  mid<60s,  program  verification  is  concerned  with  establishing  the 
consistency  between  a  program  and  its  specification,  the  specification  being  a  pair  of  assertions 
called  the  pre-  and  post-  conditions.  These  conditions  arc  usually  expressed  in  predicate  calculus 
or  some  other  formal  logic.  Any  practical  mechanization  of  Find’s  method  requires  all  loops  of  the 
program  to  be  RentS  by  assertions.  The  auertions  are  expressed  in  the  same  logic  as  the  program’s 
specifications.  The  program  annotated  by  assertions  can  be  viewed  as  consisting  of  paths,  a  path 
being  defined  as  a  sequence  of  program  statements  bracketed  by  assertions.  Each  path  defines  what 
is  called  a  verification  condition,  a  predicate  wluch  if  true  indicates  that  the  path  is  correct  with 
respect  to  its  bracketing  assertions.  The  program  is  verified  if  all  of  its  verification  conditions  are 
verified.^ 

*  As  dcaoibed  Utez,  tb«  model  ii  sot  zaatiictcd  to  %  baesr  ordeiias  of  aomity  lavaU. 

*To  be  predae,  tbia  ptocoaa  oaly  oatabliahea  partial  corrcctacaa:  tbc  program  aatiafioa  ita  aaaertioaa  wbearrer  it 
termiaatea.  Aa  czteaaioa  of  tbe  acrificatioa  ceaditioa  paradigm  caa  be  employed  to  oatabliab  tezmiaatioa. 
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The  Floyd  paradigm  has  been  the  basis  for  most  verification  systems  developed  over  the  past  15 
years.  However,  various  extensions  to  this  paradigm  have  been  developed  and  implemented,  mostly 
in  an  attempt  to  solve  the  problems  associated  with  verifying  large  programs  that,  among  other 
things,  consist  of  many  subprograms.  These  extensions  have  led  to  what  are  called  methodologies. 
In  one  form  or  another,  all  of  these  methodologies  offer  the  following  features: 

•  The  capability  to  describe  a  system’s  behavior  in  terms  of  abstract  entities,  thus  leading  to 
specifications  that  capture  the  system’s  behavior  without  reference  to  low>level  implementa¬ 
tion  concerns.  The  implementation  concerns  one  would  hope  to  avoid  (or  at  least  postpone) 
include  concrete  data  representations  and  executable  code  the  verification  of  which  would  have 
to  involve  machine-specific  concerns.  The  expectation,  of  course,  is  that  the  abstract  specifi¬ 
cations  will  be  easier  to  produce,  understand  and  debug  than  ones  involving  implementation 
details. 

•  Hierarchical  development,  through  which  one  proceeds  in  smiH  steps  from  the  abstract  spec¬ 
ifications  to  a  concrete  description  of  the  system,  such  as  optimized  executable  code.  It  is 
through  hierarchical  development  that  the  proof  of  a  large  system  can  be  considered  as  a 
collection  of  relatively  small  proofs. 

•  Reusability,  through  which  generic  specifications  and  implementations  are  verified  and  sub¬ 
sequently  used  in  different  applications. 

Several  methodologies,  most  notably  G3rpsy  and  the  Stanford  Ada- Anna  methodology,  started 
with  a  hierarchical  programming  language  that  was  subsequently  extended  with  a  notation  for 
specifications,  typically  first-  order  logic.  Others,  most  notably,  A£rm,  FDM  and  the  two  EDMs, 
started  with  a  specification  language  and  emphasize  reasoning  about  specifications.  In  some  cases, 
the  specification  language  was  linked  to  a  programming  language.  In  some  cases  (OBJ)  there  is  a 
single  language  (aka,  a  wide  spectrum  language)  serving  for  both  specifications  and  programs. 

The  advantages  of  the  programming  language  approach  are  clear:  executable  programs  are 
verified,  and  the  user  need  learn  only  one  language.  On  the  other  hand,  it  might  be  easier  to 
incorporate  features  in  support  of  verification  and  software  engineering  into  a  specification  language, 
since  it  is  not  necessary  to  consider  executability  when  it  is  decided  what  features  to  include.  Rather 
than  debating  the  merits  of  each  approach,  we  present  a  brief  scenario  of  how  Enhanced  HDM  would 
be  used  in  the  design  and  verification  of  a  system. 

In  developing  a  system  with  Enhanced  HDM,  a  user  might  first  express  the  overall  requirements 
of  his  system,  probably  using  one  or  more  modules  which  will  constitute  the  top-level  of  the  system 
description.  At  an  abstract  level,  a  system  is  specified  in  terms  of  a  collection  of  uninterpreted  func¬ 
tions.  Some  of  these  functions  have  an  obvious  connection  with  callable  programs  (e.g.,  clos.a^e), 
while  others  are  primarily  present  for  the  purpose  of  specification,  i.e.,  do  not  correspond  to  any 
concrete  representation  or  callable  program.  Examples  of  the  latter  would  be  functions  that  record 
the  historyjoLsentunessages  or  the  setjoliailed-processors.  One  can  call  these  ghost  functions. 

The  heart  of  specification  consists  of  axioms  and  definitions,  the  purpose  of  which  are  to  express 
constraints  on  the  functions.  The  constraints  are  to  be  enforced  ultimately  by  the  implementation. 
The  developer  will  usually  enclose  these  spedfications  in  one  or  more  modules.  In  constructing 
the  specification,  he  also  might  use  previously  specified  modules  -  most  typically  parameterized 
modules  instantiated  for  current  needs.  For  example,  he  might  find  use  for  a  sets  module,  a  holder 
for  elements  without  regard  to  any  ordering. 

Once  the  top  level  specification  is  complete,  the  user  can  pose  and  verify  properties  of  the 
specification.  The  goals  of  posing  such  properties  are  to  debug  the  specifications  and  to  extend  the 
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•peciiication  with  even  more  abstract  formulas.  A  property  can  take  the  form  of  a  hypothesized 
response  to  real  or  symbolic  inputs,  or  can  be  a  general  theorems  of  the  specification. 

Next  the  user  will  want  to  take  steps  toward  an  implementation  by  making  decisions  on  how 
the  functions  of  the  top  level  are  to  be  represented.  First,  he  defines  one  or  more  next  level  modules, 
the  purpose  of  which  axe  to  provide  functions  that  will  serve  as  building  blocks  to  represent  the 
top  levd  functions.  Then  he  creates  the  representation  as  a  collection  of  mapping  functions,  one 
for  each  upper  level  function.  The  axioms  of  the  top  level  are  then  verified  to  be  theorems  of 
the  modules  of  the  next  level.  The  mappings  srill  often  be  expressed  as  definitions  and  are  quite 
similar  to  Affirm ’s  eqnational  implementation.  Using  the  power  of  the  specification  language  to 
express  mappings  often  leads  to  more  concise  descriptions  than  is  possible  with  a  programming 
language.  For  example,  it  is  usually  easier  to  assert  the  existence  of  an  element  that  satisfies  a 
certain  condition  than  to  exhibit  a  program  that  explicitly  identifies  the  element. 

At  any  pmnt  in  the  development  proceu,  operations  can  be  introduced,  an  operation  producing 
a  change  (i.e.,  a  side  effect)  to  what  are  called  state  variables.  The  notation  fo..  the  specification 
of  operations  is  that  of  Hoare  triples  (also  called  Eoare  sentences).  An  operation  cau  be  expanded 
to  a  sequence  of  operations  or,  ultimately,  into  programs  using  our  subset  of  Pascal.  As  we  will 
discuss  below,  having  operations  as  first-class  objects  in  the  specification  language  allows  the  user 
to  pose  lemmas  about  operations  that  will  be  helpful  in  structuring  a  proof. 

The  hierarchical  development  can  continue  until  a  level  is  reached,  the  specifications  of  which 
the  developer  is  prepared  to  accept  as  correct  without  verification.  If  it  is  to  be  claimed  that 
the  implementation  is  verified  the  verification  should  be  carried  down  to  a  level  consisting  of  ab¬ 
stract  programs  that  can  be  easily  (with  minimal  chance  of  error)  converted  into  executable  code. 
However,  there  is  no  obligation  on  the  user's  part  to  proceed  this  far. 

At  any  point  in  the  hierarchical  development  process,  the  user  can  decide  that  one  or  more 
interfaces  are  to  be  checked  with  respect  to  the  multilevel  security  model.  Typically,  an  interface 
will  be  that  of  a  resource  manager  (e.g.,  a  file  system)  whose  purpose  is  to  enforce  multilevel 
security  for  a  class  of  objects.  The  user  spedfies  two  modules.  One  of  these  is  in  the  stylized  form 
acceptable  to  the  MLS  tool:  operations  on  a  collection  of  objects,  each  object  being  associated 
with  a  constant  security  level.  The  other  specification  can  be  considered  as  an  optimized  version  of 
the  first  specification,  allowing  for  objects  to  be  multiplexed  among  different  security  levels.  The 
first  module  is  verified  with  using  the  MLS  tod.  Next,  the  first  and  second  modules  are  shown  to 
have  identical  external  behavior.  It  is  the  second  of  the  modules  that  is  subsequently  subjected  to 
hierarchical  refinement. 

S.4.S  Revised  Special  Specification  Language 

Revised  Special  is  used  for  expressing  all  specifications  and  proofs.  Revised  Special  is  based  on 
multi-sorted  predicate  calculus  and  is  intended  to  support  both  an  axiomatic  and  constructive 
(aka  model-ba«ed)  style  of  specification.  The  former  (also  called  property-oriented  specification) 
facilitate  the  expression  of  design-level  decisions;  in  particular,  property-oriented  specifications  can 
express  partial  properties.  The  constructive  style,  being  essentially  state  machine  specifications,  is 
often  preferred  by  engineers. 

Specifications  are  structured  into  modules  with  explicit  import  and  export  lists.  Typically,  a 
module  will  correspond  to  what  is  called  a  theory,  as  it  expresses  many  (although  not  aU).  interesting 
properties  of  a  mathematical  theory  (such  as  sets).  Some  modules,  such  as  sets,  serve  primarily 
to  provide  abstract  functions  for  the  purpose  of  specification',  they  are  never  implemented.  Other 


34 


modules,  (tudb  as  buffers),  are  refined  down  to  concrete  computational  objects;  see  below.  Module 
specifications  may  be  parameterized  by  types  and  constants  (including  function  constants),  for 
uninterpreted  -  so  that  generic  theorems  can  be  stated  and  verified.  Usually,  the  parameter  will 
be  associated  with  the  elements  that  will  be  stored  in  an  object  (such  as  in  stack),  the  elements 
used  to  index  an  object  (such  as  the  indices  of  an  array),  and  functions  defined  on  the  indexing 
elements  (such  as  ;).  Also,  a  parameter  could  correspond  to  an  nninterpreted  constant  such  as  the 
length  of  a  stack  or  to  an  error  return,  such  as  the  overflow  response  when  push  is  called  on  a  full 
stack.  Any  proof  about  a  parameterized  module  be  valid  in  all  instantiations  of  the  module. 
Actual  parameters  must,  of  course,  match  the  type  of  their  corresponding  formal  parameters,  and 
in  many  situations  it  is  necessary  that  they  should  satisfy  additional  semantic  constraints  (called 
assumptions)  expressed  in  the  body  of  the  module  specification. 

Inside  a  module,  one  nsually  declares  types,  either  nninterpreted  types  or  subfypes  of  existing 
types.  A  function  is  declared  by  giving  its  name  and  signature.  The  heart  of  the  specification  gives 
meaning  to  the  functions  declared  in  the  parameter  section  or  in  the  main  body.  Through  the  use 
of  the  Lambda  Calculus,  a  function  (without  a  name)  can  be  specified  by  giving  it  a  definition 
which  can  be  recursive.  The  other  way  a  function  can  be  specified  is  in  terms  of  axioms,  an  axiom 
typically  involving  more  than  one  function.  When  the  theory  in  question  is  an  abstract  data  type, 
the  axioms  will  have  the  appearance  of  rewrite  rules,  although  at  present  there  is  not  special-purpose 
mechanization  of  rewrite  rules.  Predicate  calculus  can  also  be  used  in  axioms.  An  important  feature 
of  Revised  Special  is  is  quantification  over  functions.  This  second  order  capability  is  usually  used 
to  define  induction  schema,  but  it  has  also  been  used  to  express  abstract  system  requirements.  For 
example,  a  specification  of  a  Crypto  system  can  include  the  assertion  that  there  does  not  exist  a 
function  that  can  decrypt  a  message  unless  the  key  is  known. 

As  indicated  above,  if  the  module  contains  parameters,  the  specification  body  can  contain 
what  are  called  assumptions  on  the  parameters.  The  assumptions  are  properties  of  the  parameters 
that  must  be  verified  to  hold  in  any  instantiation  of  the  module.  For  example,  an  assumption  might 
require  that  a  parameter  that  indexes  into  an  object  satisfies  the  properties  of  a  totally  ordered 
set.  If  the  instantiation  associates  character  sequences  with  this  indexing  parameter,  it  must  be 
verified  that  the  set  of  character  sequences  is  totally  ordered.  The  proof  requires  axioms  about 
lexical  ordering. 

The  typical  abstract  data  type  specification  is  in  terms  of  functions  that  have  as  its  arguments 
one  or  more  abstract  types.  Using  Guttag’s  terms,  the  functions  can  be  constructors,  modifiers, 
or  sdectors.  The  constructors  are  used  to  generate  all  instances  of  the  abstract  types  associated 
with  the  module.  The  general  style  is  that  of  functional  programming,  a  constructor  taking  an 
instance  of  an  abstract  type  (among  other  arguments)  and  returning  a  possibly  difference  instance. 
Modifiers  also  return  an  instance  of  the  type,  but  cannot  generate  any  instances  different  from  those 
producible  by  constructors.  Selectors  return  a  concrete  object  associated  with  particular  instance 
of  the  abstract  fype  (e.g.,  the  top  element  of  a  stack). 

Different  from  the  functional  programming  model,  most  programming  languages  are  based 
on  the  von  Neumann  computational  model.  To  provide  a  link  to  the  von  Neumann  model.  Re¬ 
vised  Special  provides  operations.  Functions  or  variables  can  be  declared  to  be  state  objects.  An 
operation,  simnar  to  a  function,  has  a  signature  that  declares  the  t3rpes  of  its  input  and  output 
arguments.  However,  different  from  a  function,  an  operation  can  be  declared  to  have  a  side  effect 
on  one  or  more  state  objects.  An  operation  op  is  specified  in  terms  of  a  Hoare  triple  of  the  form 
{P}op{Q}:  if  assertion  P  is  true  prior  to  op  being  called,  Q  will  be  true  after  the  call.  P  and  Q  will 
usuaUy  be  in  terms  of  state  objects,  P  characterizing  the  state  expected  prior  to  the  call,  and  Q 


35 


the  st»te  following  the  call.  A  Hoare  triple  can  appear  anywhere  a  boolean  expression  is  expected 
in  the  specification.  Operations  can  appear  anywhere  in  a  module  specification,  but  typically  are 
used  as  the  development  process  evolves  to  the  consideration  of  program-level  concepts.  One  can 
use  Revised  Special  to  speciiy  the  operations  of  a  conventional  von  Neumann  language;  in  such  a 
specification,  conventional  program  variables  will  be  declared  as  state  objects,  and  the  assignment 
statement  (for  example)  is  then  specified  in  terms  of  its  effect  on  particular  state  objects. 

A  module  specification  can  also  pose  lemmas  and  theorems,  properties  that  when  verified 
are  true  of  a  specification.  The  approach  to  verifying  these  properties  is  discussed  in  a  later 
section,  but  for  now  it  suffices  to  say  that  theorems  usually  express  fundamental  properties  of  the 
specification  and  lemmas  are  employed  to  facilitate  the  verification  of  theorems.  One  interesting  use 
of  Revised  Special  is  to  pose  theorems  about  sequence  of  operations  that  are  verified  with  respect 
to  specifications  for  the  individual  operations.  IHiis  application  is  discussed  in  the  next  section. 

8.4.4  Program  Verification  in  Enhanced  HDM 

The  user  can  write  and  verify  programs  written  in  a  very  small  subset  of  Pascal  (which  is  also 
a  subset  of  Ada),  the  subset  supporting  the  following  statement  types;  assignment,  if-  then-else, 
while  and  repeat-nntil.  Program  variables  are  declared  as  Revised  Special  state  variables,  and 
procedure  calls  correspond  to  Revised  Special  operations  with  actuals  substituted  for  formal  argu¬ 
ments.  Rather  than  this  language  a  subset  of  Pascal,  it  has  been  suggested  that  it  be  called 

an  abstract  programming  language;  the  possibility  of  making  the  abstract  programming  language 
a  part  of  Revised  Special  is  discussed  later.  Currently,  there  is  no  compiler  for  our  subset  of  Pascal. 

EHDM  uses  the  Hoare-triple  notation  to  express  that  a  program  is  to  be  verified  with  respect 
to  pre-  and  post>conditions.  To  facilitate  its  proof,  a  program  can  be  decomposed  into  sections. 
For  example,  the  body  of  a  while  loop  is  considered  as  a  section  separate  from  the  initialization 
of  variables  that  might  precede  the  while  loop.  The  user  can  separately  prove  the  body  and 
initialization,  and  then  indicate  that  the  proof  of  the  program  is  to  be  accomplished  by  citing  the 
proofs  of  the  separate  sections.  The  advantage  of  this  approach  are  in  allowing  the  user  to  divide 
up  his  program  into  sections  as  he  sees  best  and  to  split  off  as  lemmas  complex  properties. 

8.4.5  Hierarchical  Development 

Hierarchical  devdopment  involves  the  representation  of  a  module  in  terms  of  lower  level  modules 
and  the  verification  of  the  representation.  x 

The  representation  is  itself  a  module  that  considers  the  following.  The  user  indicates  that 
a  module  is  to  be  represented  in  terms  of  one  or  more  other  modules;  more  generally,  a  set  of 
modules  can  be  represented  in  terms  of  a  different  set,  the  two  sets  perhaps  overlapping.  Each 
abstract  type  in  the  upper  module  set  is  given  a  representation  in  terms  of  lower  module  types.  It 
might  be  necessary  to  define  what  equality  of  the  upper  level  types  means  in  terms  of  the  lower 
level  ones.  For  example,  two  stacks  each  represented  in  terms  of  an  array  and  an  integer  pmnter 
can  be  declared  as  equal  if  their  pointers  are  equal  and  the  arra3rs  are  equal  in  positions  up  to 
the  value  of  the  painter;  the  remaining  positions  in  the  array  are  of  no  consequence.  Finally,  the 
representation  contains  a  definition  for  each  function  of  the  upper  level. 

The  verification  of  the  representation  is  conceptually  straightforward.  Each  of  the  axioms  of 
the  upper  level  becomes  a  theorem  to  be  proved  of  the  module  set  of  the  representation  and  the 
lower  level  modules.  Furthermore,  the  user  is  obliged  to  state  and  verify  particular  proofs  about 
the  equality  relation  he  defined,  namely  transitivity,  reflexivity,  symmetry  and  substitutively  with 
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respect  to  all  upper  level  fuactious. 

S.4.6  The  Theorem  Prover  and  How  it  is  Used 

The  heart  of  the  theorem  prover  is  a  collection  of  decision  procedures  for  propositional  logic, 
equality  over  uninterpreted  functions  and  linear  arithmetic.  The  linear  arithmetic  package  reasons 
about  equalities  or  inequalities  that  involve  addition  and  multiplication  by  constants.  A  very 
limited  nonlinear  capability  (multiplication  by  variable  values)  is  supported.  The  key  feature  of 
the  decision  procedure  set  is  that  it  decides  automatically  whether  a  formula  in  its  domain  is  a 
theorem  or  not  a  theorem. 

In  carrying  out  a  proof  of  a  theorem  or  lemma,  the  user  will  dte  as  premises  axioms  of  the 
specification;  definitions  are  automatically  expanded,  actuals  being  substituted  for  formal.  In  citing 
the  premises,  the  user  is  indicating  his  expectation  that  his  theorem  can  be  proved  vrith  respect  to 
those  axioms. 

It  is  not  possible  to  write  specifications  for  real  systems  if  one  is  restricted  to  the  domains 
provided  by  the  decision  procedure.  A  Bevised  Special  specification  will  usually  consist  of  formulas 
in  first  and  second  order  predicate  calculus.  In  the  absence  of  any  assistance  from  the  user,  the 
prover  will  replace  all  variables  and  functions  of  the  theorem  and  dted  premises  with  arbitrary 
constants  or  constant  functions.  Although  what  results  is  in  the  domain  of  the  deddon  procedure,  it 
is  usually  not  a  theorem.  What  is  needed  to  produce  a  provable  theorem  are  particular  substitutions 
for  the  variables  and  functions. 

Substitutable  variables  are  those  that  are  universally  quantified  in  the  premises  and  existen¬ 
tially  qualified  in  the  condusion;  the  situation  is  complicated  by  the  interaction  of  universally  and 
existentially  quantified  variables,  but  still  relatively  straightforward.  The  user  is  allowed  to  pro¬ 
vide  substitutions  for  substitutions  for  substitutable  variables,  doing  so  upon  dting  premises  or  the 
theorem  to  be  proved. 

Also  induded  in  the  prover  is  a  spedal  package  called  the  Hoare  Sentence  Prover  (HSP).  The 
ESP  transforms  expressions  involving  Hoare  triples  and  user-provided  substitutions  into  formulas 
of  the  underlying  decision  procedures.  What  the  HSP  generates  is  very  dote  to  conventional 
verification  conditions,  although  it  also  allows  for  user-dted  premises. 

The  bare-bones  prover  returns  PROVED  or  UNPROVED;  it  does  not  return  RfalseS  since  the 
theorem  in  question  might  be  true  subject  to  appropriate  premises  and  substitutions.  To  assist  the 
user  in  debugging  proofs,  a  number  of  tools  are  provided. 

The  show  variables  feature  identifies  the  substitutable  variables  and  their  dependendes.  The 
proof  trace  indicates  the  theorem  under  proof  and  the  premises  after  the  substitutioiu  have  been 
made.  The  proof  debugging  aid  allows  the  user  to  play  with  a  failed  proof.  In  particular,  he  can 
explore  the  theorem  under  proof  and  each  of  the  premises,  requesting  that  the  proof  be  carried 
out  assuming  that  particular  expressions  or  subexpressions  are  assumed  to  be  true.  For  example, 
he  can  request  that  the  antecedent  P  of  a  premise  (P  implies  Q)  be  assumed  true.  This  way,  he 
can  determine  if  his  ultimate  proof  would  have  succeeded  if  he  was  successful  in  proving  P.  If  the 
answer  is  yes,  he  could  then  focus  his  attention  on  why  the  attempted  proof  of  P  was  unsuccessful. 
Note  that  the  proof  debugging  aid  does  not  allow  the  user  to  modify  substitutions;  we  will  have 
more  to  say  later  about  this  defidency.  The  proof  chain  checker  assures  that  proofs  have  been 
provided  for  everything  that  the  user  has  declared  as  provable,  i.e.,  lemmas,  theorems,  assumptions 
on  parameters  for  instantiated  modulus,  and  axioms  in  modules  that  are  subject  to  hierarchical 
refinement. 
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S.4.7  The  MLS  Tool 


view  char 


EHDM  includes  support  for  multilevel  security.  The  MLS  tool  takes  as  input  a  Revised  Special 
module  subject  to  a  few  restrictions  and  produces  a  new  module  containing  theorems  to  be  verified. 
If  these  theorems  are  successfully  proved,  perhaps  requiring  the  citing  of  premises  and  substitution 
of  variables,  then  it  is  claimed  that  the  original  module  is  multilevel  secure. 

SRI’s  model  of  multilevel  security  is  addressed  in  [FLR77]  (a  preliminary  description  of  the 
model)  and  [Rus84]  (a  description  appropriate  to  Enhanced  HDM).  The  model  assumes  a  collection 
of  security  levels.  Security  levels  are  assumed  to  contain  two  components;  a  clearance  level,  taken 
from  a  totally  ordered  set,  and  a  list  of  categories,  lists  ordered  according  to  inclusion.  The  set  of 
clearances  t3rpically  includes  the  levels  (in  order)  UNCLASSIFIED,  CONFIDENTIAL,  SECRET 
AND  TOP  SECRET.  The  set  of  categories  includes  what  are  called  need  to  know  rights,  typically 
NATO,  ATOMIC,  etc.  The  set  of  security  levels  forms  a  lattice  with  TOP  SECRET  and  all  rights 
the  topmost  clement  and  UNCLASSIFIED  and  no  rights  at  the  bottom.  For  any  pair  of  security 
levels  sll  and  al2  it  is  either  the  case  that  sll  i  s  sl2  or  NOT  (ail  {»  sl2),  the  latter  corresponding 
to  sllJt  sl2  or  all  and  sl2  being  Rincomparable.S 

Furthermore,  the  model  assumes  a  collection  of  users,  each  of  whom  is  assigned  a  security  level. 
Users  can  invoke  operations,  that  can  cause  a  state  change  and  return  a  value.  It  is  assumed  that 
users  are  Rsharing  a  systemS  by  allowing  arbitrary  interleavings  of  invocation  of  operations.  Assume 
an  arbitrary  sequence  of  operation  invocations  S  terminated  by  user  Ul  invoking  an  operation;  let 
the  value  returned  to  Ul  be  VI.  Consider  another  sequence  S2,  which  is  S  with  the  removal  of  all 
operations  invoked  by  users  whose  security  levels  al2  satisfy  N0T(sl2  js  sll).  We  say  the  collection 
ol  operations  is  a  multilevel  secure  system  if  the  sequences  Si  and  S2  yield  the  same  value  to  Ul. 
The  model  is  conceptually  simple.  It  says  that  what  a  user  can  obtain  from  a  system  cannot  be 
influenced  by  users  whose  security  level  is  not  less  than  or  equal  to  his. 

The  SRI  model  cannot  be  mechanized  directly,  as  it  implies  the  need  to  carry  out  an  induction 
over  arbitrary  sequences  of  operation  invocations.  A  trick,  to  that  developed  by  Floyd  for 

program  verifleation,  is  used  to  avoid  the  need  for  induction.  The  trick  involves  introducing  objects, 
each  of  which  is  assigned  a  security  level,  and  conriders  the  security  of  operations  individually. 
Coxisidered  abstractly,  each  operation  is  viewed  in  terms  of  the  invocation  level  (assumed  to  be 
sll),  the  objects  that  obtain  new  values  as  a  result  of  the  invocation,  and  the  objects  that  impact 
the  value  returned  to  the  users  or  those  that  impact  the  objects  that  obtain  new  values.  Then,  an 
operation  is  said  to  be  multilevel  security  if 

1.  The  value  returned  to  the  user  depends  on  objects  whose  security  levels  sl2  satisfy  sl2  ]=  sll. 

2.  The  objects  that  acquire  new  values  are  at  security  level  sl2  such  that  sU  js  sl2. 

3.  Consider  an  object  at  security  level  sl2  that  acquires  a  new  value  dependent  on  the  value  of 
an  object  at  security  level  all.  It  is  required  that  sll  jw  al2. 

The  MLS  tools  assumes  a  Revised  Special  specification  where  objects  are  partitioned  accord* 
ingly  to  security  level  and  where  each  operation  is  specified,  essentially  nsiag  a  form  of  Hoare 
triples.  For  such  a  specification,  the  MLS  tool  produces  three  sets  of  theorems  for  each  specified 
operation,  in  correspondence  with  the  three  conditions  above.  These  theorems  are  contained  in  a 
module  that  is  subject  to  verification  similar  to  any  theorem  expressed  in  Revised  Special.  Usually, 
the  theorems  are  quite  simple  -  actually  trivifd,  reflecting  the  rather  simple  property  being  verified. 

The  MLS  tool  will  find  application  in  the  analysis  of  secure  resource  managers,  a  subsystem 
responsible  for  managing  a  collection  of  objects  associated  with  a  security  levd.  Acceu  to  the 
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objects  is  provided  through  »  collection  of  operations.  A  secure  operating  system  will  have  a 
number  of  such  managers,  such  as  a  file  system,  a  directory  system,  a  virtual  memory  system,  etc. 

The  tool  assumes  that  each  object  is  assigned  a  security  level  that  is  never  changed  (the 
tranquility  principle).  In  practice,  then,  only  abstract  specifications  can  be  modeled  by  the  tool. 
Concrete  specifications  that  allow  an  object  to  be  multiplexed  among  dififerent  security  levels  are 
excluded.  A  buffer  that  is  sanitized  after  being  released  by  a  user  cannot  be  modeled. 

Access  violations  are  easily  checked,  whereby  a  user  gains  control  over  an  object  for  arbitrary 
reads  and  writes.  However,  the  tool  also  reveals  subtle  security  violations  that  result  in  information 
flow  at  a  relatively  low  rate.  These  flows  are  said  to  be  associated  with  covert  channels,  and  typically 
arise  from  operations  returning  error  conditions.  For  example,  an  object  could  be  locked  by  a  user, 
thus  denying  other  users  access  to  it.  In  the  proceu,  information  could  flow  in  violation  of  the 
model  if  the  locking  is  carried  out  by  a  user  whose  security  level  is  higher  than  those  attempting 
subsequent  access  to  the  object. 

The  MLS  has  the  potential  of  exposing  significant  security  flaws  in  the  specifications  of  real 
systems.  However,  it  is  emphasized  that  the  MLS  tool  cannot  establish  the  security  of  a  system. 
It  does  not  address  program  errors.  Furthermore,  it  only  handles  design  decisions  that  are  qtiite 
abstract. 

5.4.8  The  Implementation  of  Enhanced  HDM 

After  starting  up  the  verification  system,  the  user  with  a  conventional  glass  teletype  will  be  talking 
to  the  EMACS  editor  throughout  most  of  his  session.  He  is  free  to  create  module  specifications, 
each  of  which  will  occupy  a  file,  or  to  retrieve  some  existing  module.  The  conventional  EMACS 
commands  are  available  to  him.  Once  a  module  is  ready  to  be  processed,  the  user  will  call  on 
commands  to  parse  a  module,  typecheck  it,  and  to  prove  identified  formulas.  Error  messages  are 
displayed  in  a  separate  window  and,  where  relevant,  the  cursor  will  appear  near  the  source  of  the 
error.  Version  control  assures  that  the  most  recent  versions  of  modules  will  be  used. 

5.4.9  Conclusions 

We  view  as  a  success  the  effort  on  Revised  Special.  It  integrates  what  are  recognized  as  the  seminal 
ideas  of  specification  language  technology:  module  parameters  with  semantic  constraints,  functional 
in  addition  to  operational  (state-based)  specifications,  support  for  lambda  definitions  together  with 
general  predicate  calculus,  support  for  hierarchical  refinement  and  support  for  higher-order  logic. 
Revised  Special  provides  features  that  enhance  the  expressiveness  and  reusability  of  specifications. 
Moreover,  in  addition  to  a  specification  language,  it  is  a  first  attempt  at  a  proof  justification 
language.  The  primary  weakness  of  Revised  Special  is  the  absence  of  a  formal  semantics  (currently 
under  development),  particularly  important  since  it  combines  a  number  of  different  logics.  Also, 
not  all  of  the  features  of  the  language  are  currently  implemented,  the  language  could  benefit  form 
additional  predefined  types  (such  as  arrays  and  sequences),  and  additional  syntactic  sugar  could 
be  provided. 

The  goal  regarding  verification  of  code  was  to  improve  on  the  classical  verification  condition 
approach.  A  premise  for  the  EHDM  approach  was  the  belief  that  users  find  it  difficult  to  reason 
at  the  level  of  verification  conditions  because  much  of  the  structure  of  the  program  and  of  the 
specifications  is  lost  when  verification  conditions  are  generated.  Particularly  difficult  is  the  posing 
of  lemmas  that  have  a  dear  relationship  to  the  program  being  proved;  it  is  such  lemmas  that  are 
the  most  powerful  and  the  most  appropriate  in  explaining  a  proof.  The  EHDM  approach  to  code 
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Tcriiication  involves  rewooing  in  tetius  of  Houe  sentences.  The  progrsm  being  proved  together 
with  its  speciiicntions  are  specified  as  a  Hoare  sentence,  as  are  the  sections  of  the  program.  Thus, 
the  user  can  decompose  his  program  as  he  sees  best  to  facilitate  its  proof,  perhaps  posing  lemmas  as 
he  proceeds.  He  then  describes  the  proof  of  the  program  in  terms  of  its  pieces,  the  Hoare  Sentence 
Prover  assuring  that  the  proof  is  valid.  We  believe  that  the  basic  idea  of  reasoning  at  the  level  of 
Hoare  sentences  is  attractive,  although  the  EHDM  implementation  does  not  yet  provide  adequate 
proof  support.  In  particular,  the  assembling  of  a  proof  of  a  program  from  proofs  of  its  components 
could  be  automated.  Moreover,  the  construction  of  a  proof  of  a  program  section  often  requires 
the  user  to  consider  numerous  cases  aimnltaneously.  These  cases  usually  correspond  to  paths  in 
the  programs  and  would  yield  distinct  verification  conditions  using  the  classiral  approach.  We 
anticipate  an  approach  that  integrates  the  concept  of  verification  conditions  with  reasoning  at  the 
level  of  Hoare  sentences.  This  approach  would  benefit  the  user  by  allowing  him  to  consider  the 
eases  individually  at  first,  and  subsequently  to  assemble  them  together.  No  support  exists  for  this 
at  present. 

The  goal  for  the  Theorem  Prover  was  to  move  towards  a  Bman-machine  •ymbiosis,S  the  user 
describing  his  proof  and  the  machine  cheching  it.  Towards  this  goal,  SRI  has  developed  a  coUection 
of  decision  procedures  together  with  a  preprocessor  for  predicate  logic  that  handles  quantified 
variables  and  functions.  It  is,  then,  the  user's  responsibility  to  cite  lemmas  needed  in  his  proof  and 
to  provide  substitutions  for  free  variables  such  that  the  formulas  given  to  the  decision  procedures  are 
indeed  theorems.  The  underlying  decision  procedures  are  reasonably  fast  and  the  user  is  provided 
assistance  in  identifying  the  bound  and  substitutable  variables.  However,  users  have  found  that 
the  corutmetion  of  proofs  can  be  somewhat  more  difficult  than  it  should  be,  mostly  because  of  the 
absence  of  automated  support  for  the  construction  of  proofs.  A  formula  to  be  verified  often  consists 
of  conjunctions  in  the  conclusion,  disjunctiotu  in  the  hypotheses,  implicatioxu  in  the  hypotheses, 
and  cases  arising  from  case  or  if-then-else  statements.  In  the  EHDM  system,  the  user  must  consider 
the  formula  in  toto,  citing  axioms  and  produdng  substitutions  that  will  handle  aU  cases.  Or,  if  the 
formula  is  too  large  and  complex  to  consider  in  one  shot,  he  can  break  it  down  by  hand,  proving 
the  individual  cases,  and  then  describing  a  proof  that  assembles  the  individual  pieces  into  a  proof 
of  the  original  formula.  It  would  be  preferable  to  have  mechanical  support  for  proof  decomposition, 
particularly  since  there  are  several  interactive  theorem  provers  (e.g.,  HOL)  that  already  provide  it. 
Furthermore,  it  is  difficult  and  often  tedious  to  create  and  input  the  substitutions  for  free  variables. 
Some  mechanical  support  here  would  be  very  desirable.  An  additional  vreakness  of  the  theorem 
prover  is  the  impofsibOity  of  extending  the  decision  procedures  with  use>supplied  axioms.  For 
example,  it  would  be  desirable  to  extend  the  decision  procedures  about  arithmetic  with  facts  about 
multiplication  and  division  over  variables,  leaving  intact  the  core  decision  procedure. 

As  in  old  Special,  the  MLS  tool  handles  specifications  (called  MLS  specifications)  that  associate 
a  constant  security  level  with  objects.  Several  of  the  flaws  in  the  previous  tool  have  been  avoided, 
particularly  those  related  to  nondeterministic  specifications.  The  one  weakness  of  the  MLS  tool 
relates  to  the  absence  of  mechanical  support  for  relating  an  MLS  specification  to  the  rest  of  the 
system  under  design.  It  is  desirable  to  verify  that  an  MLS  specification  has  the  same  external 
behavior  as  one  with  a  more  concrete  representation;  the  verification  system  should  require  such  a 
proof  and  provide  support  for  it. 

The  interface  to  Enhanced  HDM,  through  EMACS  and  popup  mouse  accessible  menus,  is 
reasonably  adequate.  Ultimately,  it  would  be  desirable  for  the  communication  between  the  user 
and  the  theorem  to  be  of  a  higher  bandwidth.  Fbr  example,  substitutions  for  free  variables  could 
be  effected  by  the  user  pointing  to  expressions. 
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3.5  FASE 

5.5.1  Overview 

The  FASE  system  (Final  Algebra  Specification  and  Execution)  was  developed  at  JUinois  by  Samuel 
Kamin,  Myla  Archer,  and  Stanley  Jefferson  [Kam83,  KJA83,  KA84,  JK86j  FASE  specifications 
are  written  and  executed  using  a  final  algebra  semantics.  Final  algebra  specifications  are  similar 
to  initial  algebra  specifications  typified  by  systems  such  as  OBJ,  consist  of  an  operation  signature 
and  operation  definition  rules.  Final  algebra  operation  definitions  may — but  are  not  necessarily — 
given  in  a  restricted  form  of  rewrite  rules.  In  contrast  to  initial  algebraic  specifications,  objects 
have  abstract  representations  as  tuples  of  functions.  Essentially,  objects  are  represented  by  their 
observable  behavior.  Here,  observable  behavior  means  operations  that  permit  one  object  to  be 
distinguished  from  another.  Furthermore,  the  semantics  of  the  FASE  specification  are  those  of  a 
final  algebra  rather  than  an  initial  algebra:  that  is,  the  most  abstract  algebra  with  a  given  behavior. 

3.6.2  Execution  smd  Rapid  Prototype  Support 

The  ability  to  test  specifications  by  executing  them  is  a  major  feature  of  the  FASE  system.  How. 
ever,  it  is  possible  to  write  specifications  that  are  not  executable.  FASE  specifications  are  always 
executable  if  they  lack  quantifiers.  Specifications  with  restricted  quantification  (e.g.,  over  a  finite 
set)  are  often  executable. 

The  FASE  environment  is  integrated  with  F^anz  Lisp  permitting  the  user  to  write  Lisp  pro¬ 
grams  that  exercise  specifications.  AdditionaUy,  FASE  allows  the  user  to  move  between  specifica- 
tions  and  implementations,  thus  permitting  the  user  to  develop  a  complete  specification  and  then 
substitute  Lisp  implementations  of  some  objects  for  their  specifications. 

To  iadlitate  the  concrete  implementation  of  abstract  specifications,  FASE  supplies  a  built-in 
random  tester.  This  tester  selects  a  collection  of  expressions  and  evaluates  each  one  using  both  the 
implementation  and  the  specification;  discrepancies  are  reported  to  the  user. 

FASE  permits  the  user  to  supply  a  a  more  *human  readable’  grammar,  in  addition  to  the 
standard  Lisp-style  notation  used  in  writing  the  specifications.  This  grammar  is  supplied  in  a 
separate  file  called  the  "signature”  file.  The  grammar  is  parsed  based  on  the  Earley  algorithm,  and 
is  somewhat  more  powerful  than  the  mixed-fix  syntax  allowed  by  OBJ.  In  addition,  placing  the 
signature  in  a  separate  file  from  the  body  of  the  specification  makes  it  possible  to  provide  multiple 
grammars  for  each  specification. 

Finally,  in  [KA84]  the  following  methodology  is  suggested  for  implementors  starting  with  a 
specification: 

•  Interactive  evaluation  of  expressions  to  gain  understanding 

•  During  development  of  the  implmentation,  use  interactive  evaluation  of  test  cases  to  decide 
upon  details 

•  Use  user-defined  syntax  to  test  the  implementation 

•  Extensive  random  testing  using  the  built-in  EandTestGen 

The  execution  of  spedficatioxu  involves  both  lasy  evaluation  and  finite  functions.  Lazy  evalua¬ 
tion  is  necessary,  since  objects  are  coiuidered  to  be  infinite  structures  describing  all  future  behavior, 
and  using  eager  evaluation  would  result  in  infinite  computations. 
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Since  FASE  tpediications  generally  axe  compoted  of  finite  functions  (i.e.,  take  on  a  default 
value  at  all  but  a  finite  number  of  points)  objects  may  be  represented  by  sequences  of  (argument, 
value)  pairs  plus  a  default  value.  This  greatly  reduces  the  amount  of  work  that  must  be  done  during 
execution,  and  prevents  the  deterioration  of  performance  that  generally  results  when  as  object  is 
modified  several  times. 

3.5.S  Abstraction  Mechanisms 

Because  of  the  underlying  final  algebra  semantics,  FASE  objects  are  described  by  indicating  the 
behavior  of  distinguishing  set  operations.  In  initial  algebra  systems  such  as  OBJ,  operatioxu  are 
described  by  giving  a  method  for  calculating  their  values.  This  can  bias  implementations  based  upon 
such  spedfications,  indicating  that  the  specification  is  not  completely  abstract.  FASE  specifications 
do  not  have  this  problem,  since  only  behavior  is  described. 

5.5.4  Forms  of  Logic  Supported 

Spedfications  may  be  written  using  first>order  logic,  indnding  quantifiers.  Higher-order  logic  is  not 
supported.  There  is  no  direct  provision  for  temporal  logic;  however,  the  appropriate  axioms  could 
probably  be  added  without  difficulty. 

3.5.5  Verification  and  Theorem  Proving  Supported 

Some  work  has  been  done  to  allow  FASE  to  work  with  a  proof  tree  editing  system  called  TED. 
Theorems  may  be  stated  using  the  syntax  specified  in  the  data  type’s  signature,  and  TED  manages 
proof  sequences  by  parting  the  theorems  and  then  sending  them  to  the  user’s  choice  of  theorem- 
prover  and  remembering  the  result  of  the  proof. 

3.5.6  Specification  Checking — Completeness,  Consistency,  and  Soundness 

One  advantage  of  final  algebra  specifications  is  that  it  is  easy  to  determine  when  an  object  has  been 
completely  defined.  This  is  not  true  for  all  specification  systems:  for  example,  it  is  very  difficult  to 
determine  when  an  OBJ  object  is  complete. 

3.5.7  Examples 

There  are  two  major  styles  to  FASE  specificatiozu.  Both  involve  the  Distinguishing  Set  A  FASE 
specification  of  a  SET  done  in  an  (initial)  algebraic  style  is  shown  in  Figure  3.5.7.  In  this  specifica¬ 
tion,  the  operators  es^ty.  add,  xem  are  defined  in  terms  of  the  distinguishing  set  operator  isin. 
The  operator  nax  is  defined  using  quantification:  for  integers  ( n:Znt  ),  n  is  in  S  (isin(n.S))  and 
for  aU  integer  m  (AA  B:Xnt)  if  m  is  in  S  than  a  is  greater  than  or  equ^  to  m. 

However,  there  is  a  second  style  of  specification  which  makes  ^e  final  algebra  nature  of  the 
specification  explicit.  Such  a  specification  is  shown  in  Figure  3.5.7.  In  this  specification,  the  oper¬ 
ations  anpty,  add,  tern  are  all  defined  in  terms  of  ther  future  behavior  with  respect  to  the  dis¬ 
tinguishing  set  operation  isin.  For  example,  the  specification  for  e^ty  states  that  when  isin(n) 
is  applied  to  eapty  the  observable  result  is  always  false.  The  specification  for  adding  a  number  ■ 
to  the  set  S  states  that  the  observable  behavior  for  isinCn,  S)  is  true  if  either  n  is  in  S  or  n  was 
the  integer  just  added  (n  =  m). 
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Setoflnt 


•npty  :  ->  Setoflnt 

•dd  :  lat  S«tofInt  ->  Satoflnt 
r«a  :  Int  S«tofInt  ->  S«tofInt 
isin  :  Int  S«tofInt  ->  Bool 
■az  :  Sotofint  ->  Int 

DISTINGUISHING  SET  lain  ; 

isinCn,  aapty)  ■>  falaa  ; 

isinCn,  addCa.S))  ■>  n>m  I  iainCn.S)  ; 

isinCn,  raa(B.S))  ■>  ‘naa  t  iainCn.S)  ; 

Baz(S)  ■> 

(n:Znt) 

(iainCn.S)  t 

C(AA  B:Int)(iain(B,S)->(n>a  I  n^a)))) 

Fignre  1:  Algebraic  style  EASE  specification  for  SET 


Setoflnt 

aapty  :  ->  Setoflnt 

add  :  Int  Setoflnt  ->  Setoflnt 
raa  :  Int  Setoflnt  >>  Setoflnt 
isin  :  Int  Setoflnt  ->  Bool 
aaz  :  Setoflnt  ->  Int 

DISTINGXnSHING  SET  isin  ; 

e^ty  ■>  C  <n>  |->  false  ]  ; 
addCa.S)  ->  [  <a>  |->  a-a  I  iainCn.S)  ]  ; 
reaCa.S)  ■>  [  <n>  |->  “  a-a  t  iainCn.S)  ]  ; 
aazCS)  ■> 

(n:Int) 

(iainCn.S)  ft 

(CAA  B:Znt)(isia(B.S)->(a>a  I  a-a)))) 


Figure  2:  Final  Algebra  spedfication  of  SET 
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S.5.8  Critical  Remarks 


At  described  in  [KA84],  one  weak  point  of  the  FASE  tyttesa  is  the  inability  to  execute  tome 
natural  specifications  that  include  quantiAers.  It  is  possible  to  rewrite  these  speciAcations  to  that 
they  will  become  executable,  but  at  the  expense  of  supplying  either  a  less  abstract  deAnition  or  by 
substituting  lets  natural  deAnitions. 

Errors  are  handled  in  a  very  simple  fashion;  no  provision  is  made  for  expressing  error  recovery 
or  error  messages. 

It  is  possible  to  write  ambiguous  grammars  for  the  user-deAned  signature  Ales;  this  is  not  true 
for  OBJ.  However,  the  user>deAned  syntax  permitted  by  the  Earley  algorithm  is  more  general  than 
that  of  OBJ. 


3.6  HOL 

3.6.1  Overview 

HOL  is  a  general  theorem  proving  system  developed  at  the  University  of  Cambridge  [Gor87], 
[CGM87]  that  is  based  on  Church’s  higher-order  logic.  Church  developed  higher-order  logic  as  a 
foundation  for  mathematics,  but  it  is  a  promising  language  for  describing  computational  systems  of 
all  kinds.  HOL  can  be  used  for  proving  properties  of  anything  that  can  be  expressed  in  higher-order 
logic  including  hardware  and  software  [Joy88b],  [Joy88a].  This  section  provides  a  brief  introduction 
to  higher-order  logic  as  well  as  its  implementation  in  HOL. 

5.6.2  The  HOL  Verification  System 

Higher-order  logic  is  a  mathematical  theory;  HOL  is  a  computer  program  that  uses  higher-order 
logic  to  verify  hardware  and  software.  HOL  grew  out  of  Robin  Milner's  LCF  theorem  prover  and 
is  written  in  the  computer  language  ML. 

HOL  has  several  subsystems  that  contribute  to  its  use  as  a  verification  environment: 

a.  Several  theories,  including  booleans,  individuals,  numbers,  products,  sums,  lists,  and  trees. 
These  contain  the  five  axioms  that  form  the  basis  of  higher-order  logic  as  well  as  a  large 
number  of  theorems  that  follow  from  them. 

b.  Rules  of  inference  for  higher-order  logic.  These  rules  contain  not  only  the  eight  basic  rules 
of  inference  from  higher-order  logic,  but  also  a  large  body  of  derived  inference  rules  that 
allow  proofs  to  proceed  using  larger  steps.  The  HOL  system  has  rules  that  implement  the 
standard  introduction  and  elimination  rules  for  Predicate  Calculus  as  well  as  specialised  rules 
for  rewriting  terms. 

c.  Canned  methods  of  proceeding  in  a  goal  directed  fashion  called  tactics.  Tactics  are  functions 
that  embody  knowledge  about  commonly  used  proof  techniques.  These  tactics  can  be  applied 
to  goals  to  produce  simpler  goals,  a  number  of  subgoals  that  prove  the  original  goal  and  so 
on.  Tactics  can  never  be  used  to  build  an  incorrect  proof  since  each  of  them  must  include  a 
justification  for  the  tactic  in  the  form  of  an  already  proven  HOL  theorem. 

Examples  of  tactics  include  REVRITEJTAC  that  rewrites  a  goal  according  to  some  previously 
proven  theorem  or  definition,  GEN.TAC  that  removes  unneeded  "forall”  clauses  from  the  front 
of  terms,  and  EQ.TAC  which  says  that  to  show  two  things  are  equivalent,  we  should  show  that 
they  imply  each  other. 

d.  A  proof  management  system  that  keeps  track  of  the  state  of  a  proof  and  manages  goals  and 
tubgoals. 

e.  A  metalanguage  for  programming  the  verification  system.  The  metalanguage  for  HOL  is  ML, 
the  language  in  which  HOL  is  written.  ML  is  a  type  pol3rmorphic,  lambda  calculus-based 
functional  language.  ML  is  a  powerful  programming  language  in  its  own  right  and  has  been 
described  in  [GMW79].  Using  the  metalanguage,  tactics  can  be  put  together  to  fonn  more 
powerful  tactics,  new  tactics  can  be  built,  and  results  of  proofs  can  be  made  into  new  theories 
for  later  use.  The  metalanguage  makes  the  verification  system  extremely  flexible. 

Terms  There  are  four  kinds  of  terms  in  HOL: 

1.  Variables 

2.  Constants 
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Operator 

Application 

Meaning 

m 

tl  ■  t2 

tl  equals  t2 

s 

tl,t2 

the  pair  tl  and  t2 

/\ 

tl  /\  t2 

tl  and  t2 

\/ 

tl  \/  t2 

tl  or  t2 

»«> 

tl  ■■>  t2 

tl  implies  t2 

<«> 

tl  <■>  t2 

tl  if  and  only  if  t2 

Table  1:  HOL  Infix  Operators 


Binder 

Application 

Meaning 

1 

!x.t 

for  all  X,  t 

?x.t 

there  exists  an  x  such  that  t 

c 

Ox.t 

choose  an  x  such  that  t 

Table  2:  HOL  Binders 


3.  Function  applications 

4.  Abstractions 

Variables  and  constants  are  denoted  by  any  sequence  of  letters,  digits,  underlines  and  primes 
starting  with  a  letter.  Constants  are  distinguished  in  the  logic  and  any  identifier  that  is  not  a 
distingTiished  constant  is  taken  as  a  variable. 

Function  application  is  denoted  by  juxtaposition.  Thus  a  term  of  the  form  "tl  t2"  is  an 
application  of  the  operator  tl  to  the  operand  t2.  Its  value  is  the  result  of  applying  tl  to  t2. 

An  abstraction  denotes  a  function  and  takes  the  form  ”\x.t".  ^  An  abstraction  "\  z.t"  has 
two  parts:  the  bound  variable  x  and  the  body  of  the  abstraction  t.  It  represents  a  function,  f ,  such 
that  "f  (x)  •  t".  For  example,  "\  y.2«y"  denotes  a  function  which  doubles  its  argument. 

Constants  can  belong  to  two  special  syntactic  classes.  Some  constants  are  declared  to  be 
infix.  Infix  operators  take  two  arguments  and  are  written  "randl  op  rand2''  instead  of  "op  randl 
rand2" .  Table  1  shows  several  of  HOL’s  built-in  infix  operators. 

Another  special  class  that  constants  can  belong  to  is  the  class  of  binders.  A  familiar  example 
of  a  binder  is  V,  written  in  HOL  as  ! .  If  c  is  a  binder,  then  the  term  "c  x.t"  (where  x  is  a  variable) 
is  written  instead  of  "cf\z.t}".  Table  2  shows  several  of  HOL’s  built-in  binders. 

Types  HOL  is  strongly  typed  to  avoid  Russell’s  paradox.  ’  Every  term  in  HOL  is  typed  according 
to  the  following  recursive  rules: 

•  Each  constant  and  variable  has  a  fixed  type,  letter. 

•  If  X  has  type  a  and  t  has  type  the  the  abstraction  \x.t  has  the  type  (a  -*  0). 

•  If  t  has  the  type  (a  -»  0)  and  u  has  the  type  a,  the  the  application  t  u  has  the  type  0. 

Types  in  HOL  are  built  from  type  variables  and  type  operators.  Type  variables  are  denoted 
by  a  »«quence  of  asterisks  (*)  followed  by  a  (possibly  empty)  sequence  of  letters  and  digits.  Thus 

^The  ASCn  symbol  \  is  used  ia  place  of  the  (reek  letter  X  which  is  cwtomarily  used  to  represent  an  abstraction. 

’RnsaeU’s  paradox  is  the  case  where  in  a  hi(h-order  logic,  one  defines  a  predicate  that  leads  to  a  contradiction. 
Specifically,  snppose  that  we  define  P  as  P(z)  ••  z(x)  where  denotes  negation.  P  is  tme  when  its  argnment  applied 
to  itself  is  false.  Applying  P  to  itsdf  leads  to  a  contradictian  since  P(P)  >  P(P).  This  is  prevented  by  typing  since 
in  a  typed  system  the  type  of  P  would  not  allow  it  to  be  applied  to  itself. 
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Operator 

Arity 

Meaning 

bool 

0 

booleans 

ind 

0 

individuals 

num 

0 

natural  numbers 

(*)list 

1 

lists  of  type  * 

(*,*e)prod 

2 

products  of  *  and  ** 

(*,**)sum 

2 

coproducts  of  *  and  ** 

(•,**)fun 

2 

functions  from  *  to  ** 

Table  3:  HOL  Type  Operators. 

*,  ***,  and  «ab2  are  all  valid  type  variables. 

Type  operators  construct  new  types  from  existing  types.  Each  type  operator  has  a  name 
(denoted  by  a  sequence  of  letters  and  digits  beginning  with  a  letter)  and  an  arity.  If  <ri, . . . ,  On  are 
types  and  op  is  a  type  operator  of  arity  n,  the  (oi, . . . , (rn)op  is  a  type.  ^  A  type  operator  of  arity 
0  is  a  type  constant. 

HOL  has  several  built-in  type  operators  which  are  listed  in  Table  3.  The  type  operators  bool, 
ind,  and  ftm  are  primitive.  HOL  has  a  special  syntax  that  allows  (*,**)prod  to  be  written  as  (« 
•  ••),  («,«*)8Uffl  to  be  written  as  (*  ♦  *•),  and  (*,**)fun  to  be  written  as  (*  ->  **). 

The  Choice  Operator  The  axiomatization  of  HOL  uses  Hilbert’s  choice  operator  Q.  This  is  a 
binder  with  type  given  by: 

0  :  (*->bool)->* 

The  idea  is  that  if  f  :t7->bool  then  denotes  some  value  v  such  that  "f  (v)"  is  true. 

For  example,  "Cx:num.x«xa2S"  denotes  5  (but  not  -5  as  the  type  nun  only  contains  the 
non<negative  integers).  An  interesting  side-effect  of  the  choice  operator  is  that  all  types  must  be 
non-empty  since  the  term  "4x:t  .T"  is  a  non-determinant  member  of  the  type  t;  this  member  must 
exist. 

Sequents,  Theorems,  and  Inference  Rules  The  HOL  system  supports  proof  by  natural  de¬ 
duction.  Assertions  in  HOL  are  not  just  boolean  formulae  asserting  some  independent  truth,  but 
are  of  the  form  (A,C)  where  A  is  a  set  of  assumptions  and  C  is  the  conclusion.  The  assertion  states 
that  if  all  the  formulae  in  set  A  are  true  then  so  is  the  formula  in  C.  This  forms  a  sort  of  sequent 
calculus  and  is  very  similar  to  the  way  proofs  are  carried  out  by  humans  and  thus  represents  a 
natural  proof  environment  than  other  systems.  The  form  (A,C)  is  called  a  sequent 

A  theorem  is  a  sequent  that  has  a  proof.  This  means  that  the  truth  of  the  sequent  has 
been  established  through  rules  of  inference  from  other  theorems.  There  are  certain  distinguished 
theorems  called  axioms  that  are  taken  as  true  without  proof.  Axioms  are  necessary  as  a  starting 
point.  Naturally,  any  good  proof  system  will  have  as  few  axioms  as  possible. 

A  proo/ consists  of  a  series  of  steps  that  show  that  the  sequent  to  be  proven  can  be  derived 
ffom  already  proven  theorems  using  the  rules  of  inference.  Most  proofs  in  HOL  take  place  in  a 
goal-directed  maimer,  meaning  that  the  sequent  to  be  proven  is  written  down  and  then  treated  as 
a  goal  which  is  broken  down  into  subgoals  until  the  subgoals  are  reduced  to  a  point  that  they  are 
trivial  to  prove  (i.e.  they  are  already  theorems  themselves). 

*Note  that  type  opcraton  are  peatAz  while  normal  function  application  is  prefix  or  infiz. 
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There  are  special  kinds  of  axioms  called  definitions.  A  definition  is  an  axiom  of  the  form  c«t 
where  c  is  a  constant  and  t  is  a  term  without  free  variables.  A  constant  c  is  said  to  be  defined  in 
a  theory  if  there  is  only  one  axiom  in  the  theory  containing  c  and  that  axiom  is  a  definition.  A 
theory  in  which  all  the  axioms  are  definitions  is  said  to  be  definitional.  This  is  important  because 
definitional  theories  have  the  property  that  they  cannot  introduce  any  new  inconsistencies  to  the 
system.  This  property  is  known  as  conservative  extension. 

All  axioms,  definitions,  and  theorems  are  stored  relative  to  a  theory.  A  theory  is  a  set  of  type 
operators,  constants,  axioms  and  parent  theories.  Parent  theories  provide  for  a  hierarchy  in  which 
the  contents  of  an  ancestor  theory  are  available  in  the  child  theory.  Higher>order  logic  is  extended 
by  defining  new  theories.  To  use  a  theory,  one  declares  it  a  parent  of  the  theory  currently  being 
drafted  and  then  all  of  the  components  of  the  parent  are  available  for  use  in  the  new  theory. 

Goal  Directed  Proofs  in  HOL  The  approach  to  proving  theorems  that  is  used  in  HOL  is  due 
to  Robin  Milner.  He  originally  developed  the  approach  for  a  proof  system  called  LCF.  LCF  was 
designed  for  reasoning  about  recursively  defined  functions.  The  HOL  system  is  a  direct  outgrowth 
of  LCF. 

A  goal  is  a  sequent,  that  is,  it  has  a  list  of  assumptions  and  a  conclusion.  In  general,  a  goal 
that  is  to  be  turned  into  a  theorem  will  not  have  any  assumptions,  and  so  the  list  of  assumptions 
will  be  empty.  After  the  goal  has  been  proven,  the  sequent  will  have  a  proof,  if  it  is  indeed  true, 
and  becomes  a  theorem  (recall  that  a  theorem  is  a  sequent  with  a  proof). 

In  HOL,  a  proof  is  a  function  that  turns  a  list  of  theorems  into  a  theorem.  We  can  obtain  proofs 
by  applying  tactics.  A  tactic  is  a  function  that  takes  a  goal  as  its  parameter  and  produces  a  list 
of  tubgoals  and  a  proof.  When  the  subgoals  are  proven,  they  will  each  have  associated  theorems. 
Applying  the  proof  to  the  list  of  theorems  proving  the  subgoals  produces  a  theorem  for  the  original 
goal.  For  example,  suppose  that  T  is  a  tactic  and  g  is  a  goal.  Evaluating  T  g  results  in  a  list  of 
subgoals  and  a  proof,  [  g_l  ;  g_2  ; . . .  ;gm}  and  p.  Eventually,  after  proving  each  of  the  subgoals 
(using  tactics)  we  will  have  a  list  of  theorems,  [  tjl  ;  ;  ...  ;t.n  ].  If  T  is  a  valid  tactic, 

applying  p  to  that  list  of  theorems  achieves  g  and  the  proof  is  complete.  Tbctics  will  be  discussed 
in  detail  in  a  later  section. 

S.6.S  Axiomatic  Basis  for  HOL 

This  section  discusses  the  mathematical  foundations  of  HOL.  Moreover,  it  discusses  the  way  this 
foundation  is  implemented  in  HOL.  Higher-order  logic  is  based  on  Church’s  typed-A-calculus. 
There  are  many  formulation  of  this  logic.  The  one  used  in  HOL  is  very  MTnil^r  to  the  one  discussed 
in  (And86]. 

AD  of  the  data  objects  in  HOL  are  classified  according  to  their  membership  in  sets.  For 
example,  3  is  of  the  type  nua  because  it  belongs  to  the  set  containing  aD  of  the  natural  numbers. 
Types  in  higher-order  logic  are  expressioiu  that  denote  sets.  AD  types  in  higher-order  logic  must 
denote  non-empty  sets.  This  is  enforced  by  the  aan.type  function  t^  requires,  in  addition  to  the 
representation  for  the  new  type,  a  theosem  proving  that  it  is  non-empty. 

At  the  heart  of  HOL  are  five  axioms.  Axioms  can  neither  be  proven  or  disproven.  They 
represent  what  we  beUeve  to  be  true  about  the  world.  A  complete  discussion  of  the  ^iSoTn«  on 
which  HOL  is  based  is  beyond  the  scope  of  this  report,  but  a  brief  discussion  should  shed  some 
Ught  on  what  they  mean.  Here  are  the  five  axioms: 

1.  The  boolean  cases  axiom 
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BOOL-CASES-AX  I-  !t:bool.  (t«T)  \/  Ct«F) 

s&yt  that  every  boolean  object  is  either  true  of  false. 

2.  The  implication  antisymmetry  axiom 

IMP.AHTISYM.AX  I-  !tl  t2.  (tl  — >  t2)  — >  (t2  ••>  tl)  ••>  (tl  ■  t2) 

states  that  if  tl  implies  t2  and  t2  implies  tl,  then  tl  and  t2  are  equal.  In  some  sense,  this 
axiom  relates  implication  and  equality. 

3.  The  f^-axiom 

ETA.AZ  I-  !t:*->**.  (\x.  t  x)  ■  t 

states,  in  a  round-about  way,  that  two  functions  are  equal  if  they  pve  the  same  results  when 
applied  to  the  same  arguments.  This  property  is  called  txtensionoJxty.  For  example,  the 
f^-axiom  states  that  A  x  .  sin  x  and  sin  are  the  same  function. 

4.  The  select  axiom 


SELECT.AX  I-  !P:*->bool.!x.  P  x  -«>  PfC  P) 

states  that  the  choice  operator,  when  used  with  a  predicate  expressing  a  particular  property 
returns  an  element  that  satisfies  that  predicate.  This  really  just  defines  the  meaning  of  the 
choice  operator,  as  we  have  discussed  it,  in  a  formal  manner. 

5.  The  infinity  axiom 

IfFIIITy.AX  I-  ?f :ind->ind.  OBE.OHE  f  /\  '(OSTO  f) 


states  that  there  is  a  set,  called  :ind  that  has  an  infinite  number  of  members. 

f^om  these  five  axioms,  aU  of  the  thousands  of  theorems  that  make  up  HOL  can  be  derived. 
In  addition  to  the  derived  theorenu,  we  can  also  make  use  of  definitions.  Recall  from  our  brief 
discussion  of  definitions  and  the  principal  of  conservative  extension  that  definitions,  while  techni¬ 
cally  axioms,  cannot  undermine  the  soundness  of  a  logical  system.  Thus,  we  can  define  a  number 
of  funiHar  logical  objects  using  the  primitive  constants  ■,  ■■>  and  •.  Some  of  these  include: 


T.DEF 

FORALL_DEF 

EZZSTS.DEF 

AHD.DEF 

0R.0EF 

IFF.DEF 

r,DEF 

■OT.DEF 


-  T  ■  ((\x:*.x)  ■  (\x:*.x)) 

-  !  ■  \P:*->bool.  P»(\x.T)  (binder) 

-  ?  •  \P:*->bool.  P(4  P)  (binder) 

"  A  ■  t2.!t.  (tl»»>t2»«>t)»»>t  (infix) 

"  \/  ■  t2.!t.  (tl»*>t)“>(t2»»>t)»«>t  (infix) 

-  <■>  ■  \tl  t2.  (tl««>t2)  A  (t2»»>tl)  (infix) 

-  F  ■  !t.t 

-  "  •  \t.  t  ■■>  F 
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Ajciomt  and  theorems  represent  the  data  in  a  verification  system  such  as  HOL.  In  order  to 
derive  theorems  from  the  axioms  given  above,  we  need  rules  of  inference  that  say  what  kinds  of 
derivations  are  legal.  The  rules  of  inference  are  a  very  important  part  of  any  system  of  logic.  If 
derivation  rules  could  be  added  to  the  system  without  regard  to  some  formal  basis,  HOL  would 
be  unreliable  and  unsound.  HOL  has  a  set  of  eight  primitive  inference  rules  from  which  all  of  the 
other  rules  in  the  system  must  be  derived.  An  inference  rule  has  the  general  form: 

A1  I-  tl  12  I-  t2  ...  In  I-  tn 

———————————————  (conditions) 


A  I-  t 

Such  a  rule  asserts  that  if  the  premises  are  proved  and  the  conditions  hold,  then  the  conclusion 
may  be  deduced.  Here  are  the  eight  inference  rules: 

1.  ASSUME  >  Given  a  term  "t",  conclude  t  h  t. 


2.  REFL  -  Given  a  term  “t",  conclude  H  t  ■  t. 

3.  SUBST  >  Perform  substitution  for  variables  in  a  theorem 


4.  BETAJCOHV  -  Perform  /3-reduction  on  a  term,  ^redcution  substitutes  a  function  argument 
into  the  function  body:  (  A  x.t[x])  u  ■  tCu]. 

5.  ABS  -  Introduce  abstractions  into  theorems. 


6.  IHSTJTYPE  -  Instantiate  type  variables. 

7.  DISCH  -  Discharge  an  assumption,  that  is,  an  assumption  on  the  assumption  list  is  moved  to 
the  conclusion  as  the  antecedent  in  an  implication. 

8.  KP  -  Perform  modes  ponens.  Given  H  tl  and  H  tl  ■•>  t2  deduce  the  theorem  K  t2. 


Inference  rules  in  HOL  are  ML  functions  that  return  a  theorem  object.  HOL’s  strong  typing 
provides  security  in  that  the  user  cannot  create  arbitrary  theorem  objects  without  using  a  rule  of 
inference.  New  rules  of  inference  are  created  from  the  primitive  inference  rules  through  function 
composition. 

All  proofs  in  HOL  can  eventually  be  reduced  to  proofs  using  the  primitive  inference  rules.  This 
is  a  very  powerful  concept  because  it  means  that  one  need  only  look  at  the  ML  code  implementing 
the  eight  primitive  inference  rules  to  trust  the  result  from  the  system.  In  most  theorem  provers, 
there  are  literally  thousands  of  lines  of  code  that  must  be  trusted  in  order  to  trust  the  result  from 
the  system.  The  code  implementing  the  eight  inference  rules  can  be  read  and  understood  in  few 
hours;  as  a  result,  it  is  fairly  easy  to  convince  oneself  of  their  correctness. 


Tketicis  and  Conversions  There  are  tsro  ways  of  going  about  a  proof.  One  way  is  to  start  with 
a  set  of  axioms  and  inference  rules  and  work  forward  until  the  desired  theorem  is  derived.  For 
example,  given  the  theorems: 

LESS.SUC  ■  I-  !  X  7  .  X  <  7  «■>  z  <  (SUC  7} 


FIVE.LESS.SIZ  •  I-  6  <  6 
and  the  modus  ponens  inference  rule 
thi  I-  th2  thl 


th2 

we  can  derive  H5  <  SUC  6  using  the  HOL  expression 
KP  LESS.SUC  PIVE.LESS.ASZX 
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The  second  way  to  prove  4  theorem  it  to  start  with  the  theorem  that  yon  want  to  prove  as  a 
goal  and  then  to  reduce  it  to  snbgoalt  nntil  the  subgoals  are  already  proven  theorems  or  axioms. 
Of  course,  each  of  the  reduction  steps  must  be  justified  in  some  way.  This  it  the  way  most  proofs 
are  done  in  HOL  and  we  will  see  many  examples  of  them. 

At  stated  earlier,  a  tactic  is  an  ML  function  that  is  applied  to  a  goal  to  reduce  it  to  subgoals. 
For  example,  a  tactic  called  MATCHJfPJTAC  could  be  used  to  prove  the  goal  from  the  previous 
example.  MATCHJfP_TAC  says  that  a  theorem  of  the  form  x  ■>>  y  can  be  used  to  reduce  a  goal  of 
7  to  a  subgoal  of  x.  The  goal  in  the  previous  example  was 
5  <  sue  6 

Using  NATCHJfPjrAC  and  LESS3UC,  we  get  a  new  subgoal  of 
5  <  6 


which  of  course,  is  trivially  true  by  the  theorem  FZVLiJESS^IX. 
Tactics  can  be  described  using  the  following  notation: 
<goal> 


<tactic> 


<goal>  <goal>  _  <goal> 

For  example,  C0NJ.TAC  is  described  by 
tl  A  t2 

CONJ.TAC 


tl  t2 

Thus  CONJJTAC  reduces  a  goal  of  the  form  (asl,''tl  /  t2")  to  two  subgoals  (asl.“tl")  and 
(asl,"t2").  The  fact  that  the  assumptions  of  the  top-level  goal  arc  propagated  unchanged  to  the 
two  subgoals  is  indicated  by  the  lack  of  mention  of  assumptions  in  the  notation. 

Another  example  is  XVDUCTJTAC,  the  tactic  for  domg  mathematical  induction  on  the  natural 
numbers: 

la-tCn] 


mmummmmmmMmmmmmmmmmmmm,  IBDUCT.TAC 

tCo]  tCa]  tCsuc  ■] 

ZNDUCTJTAC  reduces  a  goal  of  the  form  (asl.'Ma.tb]"}  toabasis  subgoal  (asl,''t[0]")  and  an 
induction  step  subgoal  (tCsi]  .aBl,"tCSUC  ■]").  Note  that  the  induction  hypothesis,  "tCn]"  has 
been  appended  to  the  list  of  assumptions. 

Thctics  provide  a  way  of  doing  proofs  in  HOL  that  closely  mimics  the  way  one  does  proofs 
in  mathematics.  For  example,  it  is  quite  common  in  a  proof  of  equality,  "x  ■  j",  to  prove  two 
subcases,  namely  "x  ■«>  y"  and  "y  ■•>  x".  HOL*s  EQJTAC  does  precisely  this.  The  following  is  a 
brief  description  of  some  of  the  most  commonly  used  tactics: 

1.  GEUAC  is  used  to  reduce  goals  of  the  form  "!  x  .  tCx]"  to  a  goal  of  the  form  "tCxl". 
In  an  informal  proof,  one  would  commonly  drop  a  universal  quantification  whose  scope  is  the 
entire  term  since  it  is  understood  that  free  variables  are  taken  to  be  universally  quantified. 

2.  ASMjCASESJTAC  is  used  to  consider  alternative  cases.  In  an  informal  proof  of  a  goal  such  as 
"if  X  than  y  alee  x"  one  would  show  that  if  "x”  is  true  then  "y"  is  true  and  if  "x"  is  false 
then  "z"  is  true.  "ASMjCASESJTAC  x"  reduces  a  goal  to  two  subgoals,  one  with  "x"  added  to 
the  assumption  list  and  one  with  "  x"  added  to  the  assumption  list.  When  both  goals  are 
proven,  the  original  goal  is  considered  proven. 


3.  EQJTAC,  as  described  above,  is  used  to  reduce  a  goal  involving  equality  to  two  subgoals,  one 
with  the  implication  from  right  to  left  and  the  other  with  implication  from  left  to  right. 
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4.  REWRITEJTAC  is  used  to  rewrite  u  goal  using  known  theorems.  It  also  performs  simple  boolean 
simpliAcation.  In  an  informal  proof  one  commonly  says  “...and  now,  because  z  ■  y...”  mean¬ 
ing  that  the  goal  is  simplified  using  the  theorem  t-z  ■  y  by  algebraic  manipulation,  tt 
REWRITE.TAC  takes  a  list  of  theorems  and  rewrites  the  goal  with  them  to  produce  a 
subgoal. 

5.  ST11IP.JAC  is  used  with  goals  containing  implications.  If  the  goal  has  the  form  z  ■■>  y  we 
can  assume  z  is  true  since  if  it  is  not,  the  goal  is  trivially  true  by  the  definition  of  implication. 
STRIP JTAC  removes  the  antecedent  from  the  implication  and  adds  it  to  the  assumption  list. 
The  consequent  is  the  new  goal. 

6.  EXISTSJTAC  is  used  to  pick  a  value  for  an  existentially  quantified  variable.  This  is  a  reasonable 
thing  to  do  since  an  existentially  quantified  theory  merdy  states  the  existence  of  a  single  value 
whi^  makes  it  true.  Certainly  if  we  can  pick  su^  a  value  for  our  goal,  then  the  goal  is  true. 
EXISTS JAC  “x"  reduces  a  goal  of  the  form  “?  y.t  [j]  "  to  a  goal  of  the  form  “t  Cy/x]  ". 

A  tactic  is  an  ML  functions  that  maps  an  argument  of  t3rpe  goal  (taza  list  •  ten)  to  a 
pair  consisting  of  a  list  of  subgoals  and  a  validation.  A  validation  is  a  function  that  takes  a  goal 
list  and  produces  a  theorem.  If  the  theorem  corresponds  to  the  original  goal,  then  the  tactic  has 
succeeded  in  proving  the  goal. 

Because  the  result  of  the  validation  is  of  type  tha,  it  must  use  ML  functions  that  return  that 
type.  We  have  already  seen  functions  that  return  objects  of  type  tha,  they  were  inference  rules. 
In  some  sense,  tactics  let  the  user  do  a  goal  directed  proof,  all  the  while  building  a  large  forward 
proof  as  the  validation.  Goal  directed  proof  in  HOL  is  just  a  way  of  getting  the  system  to  keep 
track  of  the  det^  of  the  forward  proof  for  yon. 

Because  all  steps  taken  by  tactics  must  eventually  be  validated  by  an  inference  rule,  tactics  can 
never  prove  a  false  statement.  Tactics  can,  however,  look  like  they  are  working  and  not  really  be 
valid.  They  won’t  produce  a  “wrong”  proof,  but  they  will  waste  your  time.  You  should  be  careful 
to  ensure  that  tactics  you  write  are  valid. 

Ikcticals  A  tactical  is  an  ML  function  that  returns  a  tactic  (or  tactics)  as  result.  Tacticals 
are  used  to  combine  existing  tactics  into  new  tactics.  They  are  used  extensively  in  HOL  proofs. 
The  most  commonly  used  tactics  are  ORELSE,  THEN,  TEENL  and  REPEAT  which  are  described  in  the 
following  paragraphs. 

The  tactical  THEN  corresponds  to  sequencing  in  programming  flow  control.  The  specification 
ofTBENu 

THEN  :  tactic  •>  tactic  ->  tactic 

If  T1  and  T2  arc  tactics  then  T1  TEEN  T2  is  a  tactic  which  first  applies  Tl  and  then  applies  T2  to 
oil  the  subgoals  produced  by  Tl. 

The  tactical  ORELSE  corresponds  to  alterxmtion  in  programming  flow  control.  The  specification 
of  ORELSE  is 

ORELSE  :  tactic  ->  tactic  •>  tactic 

If  Tl  and  T2  arc  tactics  ORELSE  Tl  ORELSE  T2  is  a  tactic  which  first  tries  Tl  and  then  if  Tl  fails 
tries  T2. 

The  tactical  THENL  corresponds  to  roughly  to  parallel  execution  in  programming  flow  control. 
The  specification  of  THENL  is 

THENL.:  tactic  •>  tactic  list  ->  tactic 

If  T  is  a  tactic  which  produces  n  subgoals  and  Tl . Tn  are  tactics  then  the  tactic  T  THENL 


52 


[T1 : . . .  ;Ta]  first  applies  T  and  then  applies  Ti  to  the  ith  snbgoal  produced  by  T.  THENL  is  used 
when  one  wants  to  do  different  things  to  different  subgoals. 

The  tactical  REPEAT  corresponds  to  looping  in  programming  flow  control.  The  specification  of 
REPEAT  is 

REPEAT  :  tactic  ->  tactic 

If  T  is  a  tactic  then  REPEAT  T  is  a  tactic  that  repeatedly  applies  T  until  it  fails. 

As  a  simple  example,  the  following  is  a  tactic  built  using  tacticals  and  some  of  the  tactics  that 
we  saw  in  the  last  section: 

(REPEAT  CEN.TAC)  THEN  EQ.TAC  THEN  (EXISTS.TAC  »x"  ORELSE  STRIP.TAC) 

This  tactic  applies  GENJTAC  repeatedly  to  the  goal  until  all  of  the  universal  quantifiers  have  been 
stripped,  breaks  the  equality  into  two  subgoals  using  implication  and  then  either  uses  EXZSTSJTAC 
to  pick  a  value  for  an  existentially  quantified  variable  of  uses  STRIP JTAC  to  strip  the  antecedent 
from  the  goal. 

Conversions  Conversions  are  a  very  important  part  of  the  HOL  system.  References  [Pau83]  and 
[Pau87]  give  a  more  detailed  introduction  to  conversion. 

Conversions  are  functions  that  map  terms  into  theorems.  Conversions  play  an  important  role 
in  rewriting  terms,  manipulating  goals  and  writing  decision  procedures.  As  an  introduction,  let’s 
look  at  one  of  the  most  basic  conversions  REWRlTEjCONV.  REWRITEjCONV  takes  a  single  argument  that 
is  an  equality  theorem  and  returns  a  convenion  for  that  specific  theorem.  Using  this  conversion 
produces  a  theorem  tailored  to  the  particular  term  given  to  it.  For  example,  suppose  we  create  a 
conversion  called  le8s_conv  using  REWRITEjCONV  and  LESSJTHM. 

LESS.THM  ■  I-  !(a:nuB)  (n:nuB).  ■  <  (SUC  n)  •  (a  ■  n)  \/  a  <  n 

let  less.conv  •  REHRITE.CONV  LESS.THM; ; 

We  can  use  this  conversion  to  produce  instantiations  of  LESSJTHM. 
less.conv  "a  <  (SUC  n)*';; 

I-  a  <  (SUC  n)  ■  (a  •  n)  \/  a  <  n 

less.conv  ''(5^6)  <  (SUC  (5*6;)";; 

I-  (5  ♦  6)  <  (SUC(5  ♦  6))  •  (6  ♦  6  -  S  ♦  6)  \/  (5  ♦  6)  <  (5  ♦  6) 

less.conv  "n  <  a";; 
evaluation  failed  terB.aatch 

Note  that,  if  possible,  the  conversion  produces  a  theorem  that  is  a  tpeeialixatipn  of  the  theorem 
pven  to  REWRITEJCONV  such  that  its  left-hand  aide  matches  the  given  term.  The  last  example  shows 
that  the  conversion  fails  if  no  match  is  possible. 

ConversionsJs  Conversionals  are  to  conversions  as  tacticals  arc  to  tactics.  They  are  operators 
for  putting  conversions  together.  TBENC  is  the  sequencing  operator  for  conversions.  The  expression 
(cl  THENC  c2)  t  uses  cl  to  produce  a  theorem  H  t  ■  tl  and  then  c2  to  produce  a  theorem  K 
tl  ■  t2.  The  overall  effect  is  a  theorem  H  t  •  t2  because  of  transitivity.  The  conversion  fails  if 
cither  of  cl  or  c2  fails. 

ORELSEC  is  the  alternation  operator  for  conversions.  The  expression  (cl  ORELSEC  c2)  t  uses 
cl  to  produce  a  theorem  I-  t  ■  tl.  If  that  fails,  then  it  uses  c2  to  produce  a  theorem  I-  t  ■  t2. 
The  conversion  fails  if  both  of  its  arguments  fail. 
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REPEATC  repeatedly  eppliei  a  conversioo  to  a  term  until  it  fails.  Here  is  the  implementation  of 
REPEATC 

letrec  REPEATC  eonv  t  ■ 

(Cconv  THENC  (REPEATC  conv))  ORELSEC  ALL.CONV)  t;; 

REPEATC  can  be  implemented  as  a  recursive  ML  function  that  uses  the  conversionals  THENC  and 
ORELSEC.  ALL.C0NV  is  the  identity  conversion.  It  alway  succeeds. 

Converting  Subexpressions  None  of  the  conversions  that  we  have  seen  so  far  work  on  the 

subexpressions  of  terms.  For  example, 

less.eonv  "(1  <  (SUC  n))  /\  (n  <  (SUC  p))“:; 

evaluation  failed  texB.3uteh 

The  conversion  is  applied  to  the  top  level,  that  is,  to  the  conjunction,  and  not  finding  a  match, 
fails.  We  need  to  be  able  to  apply  conversions  to  the  subterms  as  well. 

The  function  DEPTHjCOW  applies  a  conversion  to  all  the  subterms  in  an  expression  depth  first. 
Note  that  it  does  not  retraverse  a  term,  so  the  result  may  not  be  in  the  simplest  form.  Here  is  an 
example  of  its  application  to  a  simple  expression: 

(DEPTH.COIIV  less.eonv)  "(1  <  (SUC  n))  /\  (n  <  (SUC  p))";; 

I-  1  <  (SUC  n)  /\  n  <  (SUC  p)  -  ((1  •  n)  \/  1  <  n)  /\ 

((n  •  p)  \/  n  <  p) 

The  function  TOPJIEPTHJCONV  applies  a  conversion  to  all  the  snbterms  in  an  expression  in  a 
top  down  manner.  The  function  retraverses  the  result  until  no  further  conversion  can  be  applied. 
The  final  result  of  using  T0PJ)EPTH_C0W  is  always  in  its  simplest  form,  but  takes  longer  than  using 
DEPTHJCOHV. 

CONVJTAC  At  we  have  seen,  conversion  produces  a  theorem  from  a  term.  That  doesn’t  do  us  much 
good  in  a  goal  directed  proof.  HOL  provides  a  tactic  called  CONVJTAC  for  using  the  results  of  a 
conversion  in  a  goal  directed  proof.  It  takes  a  single  argument,  the  conversion  that  is  to  be  used, 
and  produces  a  tactic. 

CONV.TAC  :  (eonv  ->  tactic) 

In  essence,  CONVJTAC  applies  a  conversion  to  the  goal  and  then  returns  the  right-hand  side  of  the 
theorem  returned  by  the  conversion  as  the  new  subgoal.  If  the  conversion  fails,  then  the  goal  is 
unchanged. 

Defining  Conversions  In  order  to  understand  how  conversions  work,  the  following  example 
showing  the  definition  and  use  of  a  simple  converuon  is  presented.  Suppose  that  we  wish  to  prove 
the  following  goal: 

set.goal(D,  "inn.  (n  <■  (SUC  n))  •  ((n  <•  n)  \/  (n  •  (SUC  n)))");; 

After  rewriting  with  theorems  about  the  meaning  of  <•  and  what  it  means  to  be  less  than  the 
successor  of  something,  we  are  left  with  the  following  goal: 

"!(n:nun)  (n.’nun). 

((n  ■  n)  \/  n  <  n)  \/  (n  ■  SUC  n)  • 

(n  <  n  \/  (n  ■  n))  \/  (n  •  SUC  n)" 

Now,  of  course,  this  is  trivially  true,  but  we  stiU  have  to  do  some  rather  unpleasant  specialization 
of  the  disjunctive  symmetry  theorem  to  finish  the  proof.  We’d  like  to  be  able  to  have  a  tactic  that 
can  show  terms  like  this  are  true. 
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The  re«son  that  we  recognixe  a  goal  such  as  the  one  is  true  is  because  we  know  that  disjunction 
is  associative  and  commutative.  We  can  reparenthesize  and  reorder  the  terms  at  will.  We  want 
to  write  a  conversion  that  reassociates  the  terms  and  then  order  them  in  some  consistent  manner. 
This  is  called  *^erm  normalization.” 

In  our  conversion,  we  will  use  the  following  theorems  about  disjunction: 

DISJ.ASSOC  -  I-  !a  b  c.  a  \/  b  \/  c  -  (a  \/  b)  \/  c 

DISJ.SYM  •  I-  !(tl:bool)  (t2:bool).  tl  \/  t2  -  t2  \/  tl 

DISJ3.SYM  -  I-  !a  b  e.  (a  \/  b)  \/  c  -  (a  \/  c)  \/  b 

HOL  has  a  built-in  ML  function  «  that  defines  an  arbitrarily,  but  unique  total  order  on  terms, 
"arbool"  «  ''4";; 
falze  :  bool 

”4''  «  "arbool";; 
true  :  bool 

We  want  to  define  DISJ^YILCONV  such  that 
DlSJ.SYM.COirV  "a  \/  b"  ~>  I-  a  \/  b  •  b  \/  a  if  b  «  a 

DISJ.SYM.COMV  "(a  \/  b)  \/  c"  — > 

I-  (a  \/  b)  \/  c  •  (a  \/  c>  \/  b  if  c  «  b 
Here  is  the  ML  code  for  DISJ^YMjCONV 
let  OZSJ.SYM.COirv  t  •  ( 

let  (tl,t2)  ■  deat.diej  t  in 
if  (not  (is.diej  ti)  ft  (t2  «  tl))  then 
(SPEa  Ctl;t2]  DISJ.SYM) 

else 

let  (t3,t4)  •  dest.disj  tl  in 
if  (t2  «  t4)  then 

(SPEa  Ct3;t4;t23  DISJ3.SYM) 

else  fail 

)  ?  failwith  ‘DISJ.SYM.COHV';; 

Of  course,  this  simple  conversion  only  works  if  the  goal  has  three  or  fewer  subterms. 

We  can  srzite  a  general  version  using  DZSJ.SYM_COMV  that  works  even  when  the  goal  has  more 
than  three  subterms  as  follows: 
let  DZSJ.IORMALZZE.COirV  > 

T0P.0EPTR.C01fV  (REVIlITE_COWV  DISJ_ASSOC) 

THEHC  T0P.DEPTB.C0irV  DIS J.SYM.C0IV ; ; 

The  Bonnalisation  conversion  reazsodates  the  term  and  then  uses  TOPJ)EPTHJCOIV  to  completely 
order  the  term,  no  matter  what  its  size. 

Now  we  can  write  the  tactic.  We  want  to  normalize  an  expression  and  then  prove  it  using 
REFUTAC  if  possible.  Note  that  we  don’t  want  to  just  fail  if  the  two  sides  aren’t  equal,  we  still  want 
the  expression  normalized.  Also  note  that  REFLJAC  won’t  work  if  there  are  universally  quantified 
variables.  The  tactic  should  also  be  written  such  that  GEUTAC  is  used  only  if  the  goal  can  be  solved 
with  REFU'AC.  Here  is  the  ML  code  for  such  a  tactic, 
let  DlSJ.IOflNALZZE.TAC  > 
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COUV.TAC  i>XSJ.IIO»aLlZ£_COIiV 

THEN  (((REPEAT  GER.TAC)  THEV  REFL.TAC)  ORELSE  AU.TAC) ; ; 

This  tactic  is  very  general.  Not  only  does  it  solve  goals  where  the  disjnnctive  terms  are  equal,  but 
it  nonnalizes  unequal  terms,  so  that  we  can  determine  where  the  inequality  lies. 

S.6.4  Critical  Remarks 

This  section  r^ates  our  personal  impressions  of  EOL  after  having  used  it  extensively.  There  are 
several  points  that  should  be  made  before  a  detailed  discussion  of  the  strengths  and  weaknesses  of 
HOL  are  discussed. 

HOL  is  still  a  research  system,  not  a  commercial  product.  In  addition,  HOL  is  young  in 
relation  to  many  other  theorem  provers  such  as  Boyer-Moore  and  EHDM.  These  points  have 
several  implications: 

1.  EOL  is  not  polished.  As  an  example,  error  messages,  while  much  improved  over  earlier  ver¬ 
sions,  are  terse  and  sometimes  not  helpfuL  As  another  example,  the  help  system  is  incomplete 
and  somewhat  ad  hoe. 

2.  HOL  is  not  finished.  An  example  is  the  theory  of  numbers.  While  there  is  a  large  collection 
of  theorems  about  numbers,  they  are  ad  hoe.  A  more  careful  analysis  of  what  theorems  are 
important  might  include  other  theorems  about  numbers  in  the  base  system.  Another  example 
is  the  set  of  conversions  for  dealing  with  universal  and  existential  quantifiers.  The  set  is  by 
no  means  exhaustive  and  all  of  the  conversion  are  not  found  in  the  same  file. 

Overall,  HOL  has  great  potential,  but  there  are  many  deficiencies.  The  next  sections  will 
discuss  the  strengths  and  weatoesses  on  the  basis  of  the  following  criteria: 

1.  The  overall  usability  of  the  theorem  prover. 

2.  HOL's  formal  foundations. 

3.  The  soundness  of  the  theorem  prover  and  its  trustworthiness. 

4.  The  expressibility  of  HOL’s  specification  language  for  describing  the  structure  and  behavior 
of  hardware  designs. 

5.  The  suitability  of  HOL’s  specification  language  for  expressing  generic  designs. 

6.  The  suitability  of  HOL’s  specification  language  for  describing  systems  composed  of  hardware 
and  software. 

7.  The  suitability  of  HOL’s  specification  language  for  describing  concurrent  and  distributed 
systems. 

8.  Examples  for  which  HOL  is  particularly  wcQ-suited  and  those  it  does  not  handle  weU. 

9.  HOL's  performance  on  large  examples. 

10.  The  extensibility  of  the  system,  including  defiaing  new  types  and  decision  procedures. 

11.  The  proof  power  ei  the  HOL  environment.  Consideration  will  be  pven  to  how  automatic 
proofs  are,  the  capability  of  the  system  to  carry  out  proofs  by  iadnetion,  the  capabilities  for 
reusing  proofs,  and  the  ability  of  the  user  to  interact  with  the  prover  when  it  <*»!«  to  discover 
a  proof. 

12.  The  "software  en^oering”  features  of  the  environment,  e.g.,  its  capability  to  reason  about 
changes  to  designs,  its  support  for  modularisation  and  refinements,  its  capabilities  for  inte-  - 
grating  design  and  proof. 
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Ease  of  Use  This  section  discusses  the  overall  nsability  of  the  HOL  system.  Ease  of  nse  hinges 
on  several  factors,  among  them  the  nser  interface,  the  style  of  proof,  the  proof  management  system, 
and  theory  and  theorem  management. 

BOL’s  user  interface  is  somewhat  Spartan.  As  delivered,  it  is  nothing  more  than  a  rtad-eval- 
print  loop.  Work  should  be  done  to  supply  a  user  interface  that  takes  advantage  of  the  features 
available  on  modem  workstations  such  as  windows,  menus,  expanded  character  sets,  mouse-driven 
editing,  etc. 

The  style  of  proof  in  HOL  is  natural  and  flexible.  Proofs  can  take  place  in  a  forward,  backward, 
or  mixed  mode.  Tactics  provide  a  natural  way  of  going  about  goal-directed  proofs.  Using  tactics, 
proofs  can  be  done  in  a  manner  that  mimics  the  way  a  human  proves  theorems.  Indeed,  one  of  the 
best  ways  to  structure  a  proof  in  HOL  is  to  do  a  hand-proof  first  and  nse  the  informal  proof  as  a 
guide  in  developing  the  formal  proof. 

HOL  wmtains  a  simple  proof  management  system  based  on  a  goal  stack.  More  extensive  proof 
management  systems  exist  independent  of  HOL  that  provide  the  capability  of  editing  the  proof 
tree  at  arbitrary  points  and  pve  the  nser  the  flexibility  of  pursuing  subgoals  in  a  less  structured 
manner.  An  example  is  the  Tkeemacs  proof  editor  from  the  University  of  Illinois  [Ham88]. 

HOL  provides  a  simple  system  for  managing  theories  in  the  form  of  a  library  package  based 
on  the  UNIX  file  system.  HOL  stores  theories  in  directories  of  files  and  can  be  loaded  from  within 
HOL  using  the  load_library  command. 

Another  problem  that  arises  when  using  HOL  is  that  the  nser  frequently  knows  which  theorem 
should  be  used  next,  but  does  not  know  the  name  of  the  theorem.  This  necessitates  searching 
through  pages  of  listings  giving  the  naunes  of  theorems,  looking  for  the  particular  theorem  needed 
for  the  job  at  hand.  This  works  when  the  number  of  theorems  is  small,  but  becomes  unwieldy  for 
large  collections.  It  is  not  inconceivable  that  a  good  theory  of  numbers  would  contain  thousands 
of  theorems.  This  problem  needs  to  be  solved,  but  it  is  not  clear  what  the  best  solution  is.  It  is 
possible  that  a  database  management  system  using  pattern  matching  might  be  step  in  the  right 
direction. 

Perhaps  one  of  the  most  frustrating  areas  impinging  on  ease  of  use  is  the  quality  of  docu¬ 
mentation  about  the  system.  In  this  area,  HOL  gets  particularly  poor  marks.  Users  are  left  to 
discover  very  important  points  about  the  theorem  proves  by  chance,  or  from  informal  contact  with 
other  users.  This  should  change  in  the  future  since  Mike  Gordon  has  a  contract  to  produce  good 
documentation  for  the  system.  This  documentation  is  to  be  available  early  in  1990. 

Formal  Foundations  BOL’s  formal  foundations  are  very  strong.  HOL  is  based  on  Church’s 
typed  A-calculus  (also  known  as  higher-order  logic).  Typed  A-calculus  was  developed  as  a  formal 
basis  for  mathematics  and  has  received  considerable  attention  independent  of  its  use  in  theorems 
provers.  Difierent  logics  could,  of  course,  and  are  used  in  theorem  provers.  There  is  no  way  to  argue 
that  higher-order  logic  is  the  “best”  logic,  but  one  can  conclude  that  higher-order  logic  imposes 
no  fundamental  limitations  on  HOL.  Another  point  in  its  favor  is  that  the  theoretical  foundation 
of  HOL  is  familiar  to  people  trained  in  classical  logic.  Most  of  the  logic  is  already  known  to  the 
user  and  the  user  is  not  forced  to  kam  a  new  logic  before  beginning. 

Higher-order  logic  seems  to  be  necessary  for  building  a  trustworthy  theorem  prover.  See  the 
section  that  follows  on  trustworthiness  for  more  information.  In  addition,  higher-order  logic  allows 
generic  specifications  to  be  easily  defined. 
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Soundness  and  TVustworthiness  Simply  pat,  to  say  that  a  theorem  prover  is  sound  is  to  say 
that  one  cannot  conclude  that  false  is  true  within  the  system.  To  say  that  a  theorem  prover  is 
trustworthy  is  to  say  that  it  faithfully  implements  the  logic  upon  which  it  is  based. 

There  is  little  doubt  that  the  logic  upon  which  HOL  is  based  is  sound.  One  cannot  reach  this 
conclusion  by  proof  since  it  is  a  hypothesis  that  can  never  be  proven,  only  disproven.  The  more 
important  question  is  whether  or  not  HOL  faithfully  implements  higher-order  logic. 

HOL  is  based  on  5  primitive  axioms.  There  are  three  ways  to  create  a  new  theorem  in  HOL; 

1.  One  can  declare  it  an  axiom. 

2.  One  can  make  a  definition. 

3.  One  can  create  a  theorem  from  existing  axioms  definitions,  and  theorems  using  inference 
rules. 

While  HOL  allows  one  to  declare  arbitrary  axioms,  this  practice  is  discouraged  unlike  other 
systems  such  as  EHDM  where  this  is  the  standard  means  of  introducing  new  bases  for  proof.  Axioms 
are  distinguished  in  HOL  so  that  they  can  be  identified  in  theories,  providing  a  measure  of  safety. 

The  principle  of  conservative  extension  assures  ns  that  as  long  as  definitional  axioms  are  added 
to  the  system  then  the  system  will  remain  sound.  HOL  encourages  the  use  of  definitions.  Theories 
that  are  free  of  axioms  (that  is,  contain  only  definitions  and  theorems)  are  called  definitional  and 
are  sound  . 

An  inference  rule  is  an  ML  function  that  returns  an  object  of  type  theorem.  HOL  contains  8 
primitive  inference  rule.  Every  other  inference  rule  is  based  on  some  functional  composition  of  the 
8  primitive  inference  rules. 

The  combination  of  definitional  theories  and  a  small  number  of  axioms  and  inference  rules 
make  HOL  extremely  trustworthy.  In  order  to  be  assured  that  the  a  result  of  true  is  correct, 
one  need  only  be  convinced  of  the  correct  implementation  of  5  inference  rules  and  the  8  primitive 
axioms.  Incorrect  code  elsewhere  might  lead  the  theorem  prover  to  fail  to  return  an  answer,  but 
will  not  lead  to  an  incorrect  answer. 

Higher-order  logic  seems  to  be  essential  to  building  a  trustworthy  theorems  prover.  With¬ 
out  higher-order  logic,  it  is  impossible  to  declare  recursive  axioms  in  a  definitional  manner.  We 
have  seen  that  the  ability  to  use  definitions  ratho  than  declaring  arbitrary  axioms  is  essential  to 
maintaining  the  soundness  of  the  theorems  prover. 

Another  facet  of  trustworthiness  where  higher-order  logic  is  important  is  induction.  Without 
higher-order  logic,  the  induction  schema  cannot  be  expressed  in  the  logic  and  thus  the  induction 
cannot  be  carried  out  mechanically  in  the  system  but  is  left  to  for  the  user.  Various  first-order 
system  have  attempted  to  provide  induction  without  higher-order  logic,  but  none  have  been  sue- 
ccssfhL 

One  deficiency  of  HOL  in  the  area  of  trustworthiness  is  HOL  management  of  theories.  HOL's 
theories  are  stared  in  text  files  (which  contain  LISP  expressions)  and  thus  can  be  edited  without 
invalidating  them.  In  addition,  when  a  theory  is  changed  in  the  system,  its  descendants  are  not 
invalidated  as  they  should  be.  While  attempts  to  add  this  capability  would  probably  be  futile  due 
to  the  iiuecurities  of  the  operating  system  and  other  issues,  this  area  should  not  be  ignored  in  a 
qrstem  to  be  used  for  commercial  proofs. 

HOL  currently  does  a  good  job  of  protecting  the  user  from  accidentally  cheating  and  declaring 
something  proved  which  is  not.  It  does  far  less  to  guard  agaixut  deliberate  tampering.  Before  HOL 
is  used  in  a  commercial  endeavor,  one  would  probably  also  want  more  assurance  that  the  results 
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HOL  are  geauiae.  An  independent  proof  checker  that  checks  a  transcript  of  the  primitive 
inferences  taken  by  HOL  daring  a  proof  to  ensure  that  they  are  all  valid  and  no  shortcuts  were 
.  taken  would  solve  this  problem  since  the  user  could  not  fake  a  correct  series  of  inference  steps 
without  actually  doing  the  proof.  Proof  checkers  are  simpler  to  write  than  theorem  provers  and 
would  provide  an  added  measure  of  security. 

Ihutworthiness  has  a  downside.  HOL  is  extremely  trustworthy  precisely  because  it  requires 
that  every  theorem  be  derived  by  primitive  inference.  This  means  that  many  of  the  decision 
procedures  used  in  other  theorem  provers  for  Peano  arithmetic,  boolean  algebra,  etc.  cannot  be 
used  in  HOL  as  they  get  their  speed  from  doing  the  manipulation  of  terms  outside  the  object 
world,  that  is  without  using  primitive  inferences.  Besearch  should  be  undertaken  to  find  decision 
procedures  that  work  by  primitive  inference  but  are  fast  enough  to  be  of  use. 

Expressiveness  In  the  area  of  expressiveness,  we  will  deal  with  three  topics: 

1.  The  expressibility  of  HOL’s  specification  language  for  describing  the  structure  and  behavior 
of  designs. 

2.  The  suitability  of  HOL’s  specification  language  for  expressing  generic  designs. 

3.  The  suitability  of  HOL’s  specification  language  for  describing  systems  composed  of  hardware 
and  software. 

As  was  mentioned  in  the  preceding  section,  HOL  is  based  on  higher-order  logic.  This  gives 
HOL  incredible  flexibility  in  what  it  can  express.  Higher-order  logic  is  Taring  complete,  meaning 
that  any  thing  that  can  be  expressed  using  any  other  programming  language,  can  be  expressed  in 
HOL.  This  is  as  much  as  can  be  hoped  for  in  any  language.  In  addition,  because  of  its  higher-order 
capabilities,  specifications  expressed  in  EOL  are  generally  more  concise  and  dear  than  they  might 
be  in  some  other  notation. 

Since  HOL  is  based  on  higher-order  logic,  any  specification,  at  any  level,  can  be  parameterired, 
but  very  little  research  has  been  done  in  this  area.  One  could  easily  imagine,  for  example,  a  generic 
ALU  specification  and  implementation  that  allows  each  of  the  ALU’s  functions  to  be  specified  and 
verified  separately;  these  separate  proofs  and  specifications  could  then  be  automatically  composed 
with  the  generic  ALU  implementation  to  form  a  custom  ALU  proof.  While  this  has  not  yet  been 
done,  there  does  not  seem  to  be  any  fundamental  limitation  in  HOL  that  would  prevent  this. 

The  question  of  HOL’s  suitability  for  specifying  mixed  systems  can  perhaps  be  best  addressed 
by  example.  Jeff  Joyce  of  the  University  of  Cambridge  has  specified  and  verified  a  microprocessor 
called  Tamarok  along  with  a  compiler  for  the  miaoprocessor.  This  verification  shows  the  efficacy 
of  HOL  for  specifying  mixed  systems.  On  another  level,  since  almost  all  modem  computers  are  mi- 
crocoded,  any  verification  of  a  microprogrammed  microprocessor  demonstrates  HOL’s  capabilities 
in  this  area.  There  have  been  several  large  microcoded  examples  completed  at  different  institutions. 

PerformaLnee  on  Different  Clauses  of  Problems  Higher-order  logic  is  extremely  expressive, 
but  that  does  not  mean  that  HOL  will  perform  equally  in  all  problem  domains.  Because  HOL  has 
been  used  extensively  to  verify  hardware  systems,  there  is  a  large  body  of  knowledge  about  using 
HOL  in  this  domain  and  many  useful  techniques  have  been  developed  and  widely  disseminated. 
Researchers,  both  here  at  the  University  of  California,  Davis  and  elsewhere,  are  just  beginning  to 
use  HOL  to  verify  interesting  properties  for  software. 

Recent  work  at  UCD  has  identified  several  limitations  in  the  present  version  of  HOL  which 
make  it  difficult  to  describe  the  implementation  of  some  programs.  An  example  of  a  deficiency  in 
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this  area  is  the  inability  of  HOL  to  define  arbitrary  recursive  definitions.  HOL  does  not  allow  this 
for  good  reason  (soundness),  but  of  course,  any  real  program  will  allow  totally  recursive  functions. 
This  problem  is  non  intractable,  but  is  simply  an  example  of  the  kinds  of  issues  that  will  have  to 
be  resolved  before  HOL  is  used  to  verify  programs. 

Not  surprisingly,  HOL  seems  to  do  particularly  well  in  developing  theories  about  mathematics. 
Set  theory,  group  theory,  etc.  can  be  expressed  and  developed  quite  naturally  in  HOL.  This  is 
important  since  making  formal  proofs  tractable  requires  that  the  user  of  the  formal  system  have  a 
large  body  of  preproven  theorems  about  mathematics  readily  available. 

Performance  on  Large  Examples  HOL  has  been  used  by  several  different  researchers  to  specify 
and  verify  several  Large  Scale  Integration  (LSI)  sised  examples.  Most  of  these  are  hardware,  as  the 
raw  HOL  logic  is  suited  to  hardware  descriptions.  Besearchers  at  the  University  of  Calgary  have 
specified  and  verified  a  small  LISP-based  microprocessor  (the  SECD  microprocessor)  and  are  in 
the  process  of  verifying  another  (the  so-called  Three  Instruction  Machine,  or  TIM).  Researchers 
at  the  University  of  Cambridge  in  England,  where  HOL  was  developed,  have  verified  three  or  four 
chips  that  could  be  classified  as  ‘^ge,”  including  a  network  control  chip  and  a  microprocessor  on 
the  same  level  of  complexity  as  a  PDP<8< 

HOL  is  being  used  to  verify  the  VIPER  microprocessor.  It  appears  that  VIPER  represents 
the  upper  end  of  hardware  that  can  be  verified  using  current  techniques.  There  does  not  appear 
to  be  any  fundamental  limitation  in  HOL  that  would  limit  its  usefulness  to  small  or  medium¬ 
sized  problems,  but  new  techniques  for  structuring  proo&,  new  abstraction  mechanisms  and  more 
automated  methods  of  proof  need  to  be  explored. 

Abstraction  Mechanisms  HOL  is  weak  in  the  areas  of  structural,  behavioral  and  temporal 
abstraction.  For  example,  HOL  does  not  contain  any  built-in  theories  about  gates,  devices,  spe¬ 
cific  programming  languages,  etc.,  or  types  specific  to  hardware  specification  such  as  bit-vectors, 
words,  and  so  forth.  It  is  difficult  to  see  how  built-in  theories  of  gates  would  be  useful  without 
having  the  theorem  prover  linked  to  a  CAO  system  and  supplying  the  user  with  specification  and 
implementations  for  the  standard  libraries  of  gates  avulable  in  the  CAD  system  as  well  as  decision 
procedures  for  doing  proofs  with  them. 

Another  example  is  the  lack  of  a  formal  means  for  dealing  with  temporal  issues  -  as  would 
be  required  in  proofs  about  concurrent  programs.  There  are  techniques  to  be  sure,  but  they  exist 
outside  the  system  and  thus  there  is  no  built-in  support  for  state-based  proofs  and  reasoning  about 
temporal  issues. 

HOL  is  strong  in  the  area  of  data  abstraction.  HOL’s  type  definition  package  maintains  the 
soundneM  of  HOL  while  at  the  same  time  the  declaration  of  new  fypes  and  functions  on 

those  types  reasonably  automatic. 

The  ability  to  define  new  types  in  HOL  and  then  write  spedfications  in  terms  of  these  new  t3rpe8 
gives  HOL  a  powerful  abstraction  mechanism.  Not  all  verification  environments  are  so  powerful. 
Some  limit  the  specification  to  terms  involving  boolean  logic,  so  that  it  is  impossible,  for  example, 
to  say  abstractly  that  an  ALU  should  sum  its  inputs. 

HOL  provides  no  formal  support  for  reasoning  about  changes  to  a  design.  This  means  that  a 
small  change  to  the  implementation  of  a  design  invariably  necessitates  redoing  the  proof.  Depending 
on  how  the  proof  was  done,  this  may  be  trivial,  or  may  be  a  major  undertaking.  Many  systems  are 
structured  enough  that  with  the  appropriate  abstraction  mechanisms,  mechanisms  for  reasoning 
about  changes  to  a  design  should  be  possible.  This  represents  a  fertile  area  of  possible  research. 
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Extending  HOL  HOL’s  extensibility  is  one  of  its  strongest  points.  Indeed,  one  could  &rgue  tha-t 
to  use  HOL  is  to  extend  it  since  one  cannot  prove  a  theorem  without  adding  it  to  a  theory.  User’s 
can  add  new  theories,  types,  tactics,  conversions,  and  so  forth  to  tailor  the  system  to  their  needs. 

In  addition  to  being  extended  by  proving  theorems,  ML,  the  metalanguage  of  HOL,  provides 
a  mechanism  for  programming  the  theorem  prover  and  deJining  new  functions.  HOL  is  a  system 
that  can  be  tailored  to  a  particular  problem  domain.  One  could  imagine,  for  example,  a  hardware 
verification  environment  built  on  top  of  HOL,  linlced  to  a  CAD  system. 

HOL  is  extenuble  without  the  user  having  to  modify  the  internal  code.  In  addition,  HOL 
protects  the  user  from  mahing  extensions  that  will  make  the  system  unsound.  For  example,  we 
discussed  how  tactics  are  validated.  A  user  can  write  a  new  tactic,  but  if  the  validation  does  not 
work,  then  the  tactic  cannot  be  used  to  mistakenly  conclude  that  an  HOL  term  is  true. 

Proving  Theorems  in  HOL  HOL  is  a  interactive  theorem  prover.  It  does  not  attempt  to  carry 
out  proofs  without  user  intervention.  Proof  systems  that  attempt  to  automatically  generate  proofs 
almost  always  f^,  leaving  the  theorem  prover  in  an  unknown  state.  The  user  then  adds  another 
l^mtnit  and  tries  again.  HOL  does  not  require  user  assistance  for  every  inference,  but  the  user  is 
expected  to  guide  the  proof.  As  an  example,  the  proof  script  of  an  n-bit  ALU  we  carried  out  is 
about  600  lines  long,  but  produces  a  proof  which  takes  over  220,000  primitive  inference  steps. 

HOL  has  powerful  induction  schema  that  include  both  induction  over  natural  numbers  and 
structural  induction  over  both  built-in  and  user  defined  data  types.  HOL’s  data  abstraction  package 
includes  a  facility  for  automatically  generating  induction  tactics  for  user  defined  types. 

HOL  needs  to  be  expanded  to  include  decision  procedures  for  terms  involving  common  types 
such  as  numbers  and  booleans.  One  often  gets  to  a  point  in  a  proof  that  the  answer  is  obvious, 
but  there  are  hours  of  term  manipulation  left  to  be  done.  There  are  already  existing  algorithms 
for  dealing  with  many  of  these  situatioxu  and  they  should  be  included  in  HOL  so  that  this  kind  of 
tedious  work  can  be  avoided  where  possible. 

Software  Engineering  Features  HOL  has  no  built-in  capability  to  reason  about  changes  to 
completed  proofs.  This  is  an  area  of  active  research  and  new  ideas  could  be  easily  tested  in  EOL 
due  to  its  powerful  metalanguage,  ML. 

HOL  supports  the  modularization  of  proofs  through  the  creation  of  theories.  A  theory  is  a 
collection  of  related  theorems,  types,  definitions,  and  axioms.  For  example,  the  type  definitions 
and  theorems  about  natural  numbers  are  collected  in  a  theory  called  :nuB.  HOL  maintains  a 
hierarchical  dependency  graph  showing  which  theories  depend  on  others.  This  hierarchy  is  used  to 
provide  modular  proofs  of  correctness  that  limit  the  effect  of  changes  to  a  system  being  verified. 

HOL’s  type  checker  is  strong  and  is  used  to  maintain  soundness.  The  typechecker  has  very 
good  inferential  capabilities,  freeing  the  user  from  worrying  about  type  declarations  where  they  can 
be  inferred  from  context. 

HOL  provides  no  means  of  executing  even  simple  expressions.  This  can  be  very  frustrating 
since  one  defines  functions  and  cannot  execute  them  over  several  example  to  get  a  feel  for  thur 
correctness  before  starting  on  a  long  verification  effort.  Many  times,  one  defines  a  function,  only 
to  discover  part  way  through  a  proof  that  it  is  incorrect.  This  usually  invalidates  the  proof  so  far 
and  the  user  is  obliged  to  start  over.  On  a  more  general  level,  an  execution  facility  can  be  used  tc 
give  the  specification  writer  feedback  that  the  specification  is  correct.  A  formal  specification  that 
does  not  match  the  requirements  is  useless. 
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Concluding  Remarks  Overall,  HOL  is  a  very  capable  system  that  has  proven  itself  through  use 
in  several  large  proofs. 

There  axe  tradeoffs,  of  course,  in  the  design  and  implementation  of  theorem  provers.  HOL  is 
extensible  and  programmable;  there  is  only  a  small  amount  of  code  that  must  be  trusted.  EHDM 
and,  to  a  greater  extent,  Boyer-Moore  are  handcrafted  for  performance;  they  attempt  to  automat¬ 
ically  prove  theorems.  HOL  is  perhaps  less  focused  and,  in  some  situations,  more  difficult  to  use, 
but  much  more  flexible  and  in  the  end  stronger. 


62 


3.7  OBJ3 

3.7.1  Overview 

0BJ3  is  an  equational  programming  language  designed  for  the  specification  and  implementation  of 
abstract  data  types.  Recent  literature,  however,  demonstrates  that  OBJ3  has  many  applications. 
In  particular,  the  language  and  its  interpreter  support  testing,  debugging,  and  rapid  prototyping 
of  algebraic  specifications  of  software  systems  [GW88].  More  importantly,  specifications  can  be 
mechanically  verified,  by  using  the  interpreter  as  theorem  prover  [Gog88]. 

Because  OB  J3  can  be  used  for  all  phases  of  a  development  effort,  it  is  a  wide-spectrum  language. 
0BJ3  is  also  a  functional  language,  since  user-defined  operations  cannot  cause  side-effects. 

OBJS’s  encapsulation  unit  is  the  object  The  object  construct  corresponds  roughly  to  the 
module  or  package  constructs  found  in  other  programming  languages. 

An  object  has  a  name  and  can  contain  several  kinds  of  components.  These  components  define 
sorts  and  operations  that  are  exported  by  the  object.  Sorts  are  analogous  to  data  types;  operations 
are  analogous  to  functions.  Specifically,  an  object  can  contain:  importing  instantiations  of  other 
objects;  sort,  subsort,  variable,  and  operation  declarations;  and  equations.  Before  continuing, 
however,  some  definitions  are  necessary. 

The  fundamental  data  structure  in  0BJ3  is  the  term.  A  term  is  defined  recursively:  It  is  either 
a  variable,  a  constant  (an  operation  with  no  arguments),  or  an  operation  with  terms  as  arguments. 
A  term  containing  no  variables  is  a  ground  term.  An  0BJ3  computation  is  the  reduction  of  a  ground 
term.  A  reduction  is  the  simplification  of  a  term  according  to  a  set  of  equations.  Operationally, 
equations  are  treated  as  unidirectional  rewrite  rules. 

An  object  is  imported  when  its  sorts  and  operations  are  needed  by  the  importer.  0BJ3  supports 
several  importation  mechanisms  —  they  are  extremely  flexible.  These  mechanisms  promote  top- 
down,  modular  design.  They  are  discussed  in  more  detail,  later  in  this  section. 

A  sort  declaration  is  used  to  construct  a  user-defined  sort.  A  subsort  declaration  allows  an 
element  of  one  sort  to  be  an  element  of  another  sort. 

A  variable  declaration  allows  variables  to  be  used  in  equations.  Each  variable  is  declared  to  be 
of  a  particular  sort.  An  equation  containing  a  variable  is  an  abbreviation  for  the  set  of  equations 
obtained  by  replacing  the  variable  with  each  element  of  its  sort.  Of  course,  an  equation  may  contun 
more  than  one  variable. 

An  operation  declaration  specifies  the  name,  arity,  and  coarity  of  an  operation.  An  operation 
can  be  overloaded,  since  its  arity  and  coarity  are  part  of  its  name.  For  a  mixfix  operation,  the 
argument  positions  are  declared  by  embedding  underbars  in  the  operation  name  (e.g.,  Various 
operation  attributes  can  also  be  defined.  These  include:  associativity,  commutativity,  a  precedence, 
and  an  evaluation  strategy.  An  evaluation  strategy  specifies  the  order  in  which  the  operation’s 
arguments  are  reduced. 

An  equation  specifies  a  relationship  between  two  or  more  operations.  Thus  it  specifies  how  a 
term  can  be  reduced.  In  fact,  an  equation  is  raply  an  ordered  pair  of  terms.  If,  after  variable 
binding,  the  left-hand  side  of  an  equation  is  equal  to  a  subterm,  that  subterm  can  be  replaced  by  the 
equation’s  right-hand  side,  using  the  variable  binding.  Conditional  equations  are  also  supported.  A 
conditional  equation  is  applicable  only  when  its  associated  boolean  condition  (a  term  that  reduces 
to  true  or  false)  reduces  to  true. 
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3.7.2  Abstraction  Mechanisms 

0BJ3  supports  a  program-development  paradigm  called  parameterized  programming  [Gog84]. 
When  a  parameterized  object  is  instantiated,  an  actual  parameter  is  bound  to  each  formal  pa¬ 
rameter.  An  actual  parameter  is  also  an  object  (i.e.,  it  provides  sorts  and  operations).  0BJ3’s 
parameterization  mechanism  is  far  more  powerful  than  Ada’s  generic-package  mechanism. 

Each  actual  parameter  must  satisfy  the  theory  associated  with  its  corresponding  formal  pa¬ 
rameter.  A  theory  is  an  object-like  construct  that  specifies  the  syntactic  and  semantic  requirements 
of  an  actual  parameter. 

In  general,  an  actual  parameter  may  satisfy  a  theory  in  more  than  one  way.  The  way  in  which 
an  actual  parameter  does  satisfy  a  theory  is  specified  by  an  object-like  construct  called  a  view.  A 
view  is  a  mapping  from  sorts  and  operations  in  the  theory  to  sorts  and  operations  in  the  actual 
parameter.  Often,  crplidt  views  are  unnecessary;  0BJ3  is  quite  adept  at  determining  default  views. 

S.7.S  Forms  of  Logic  Supported 

Strictly  speaking,  an  0BJ3  specification  is  written  in  equational  logic.  Each  equation  specifies  that 
one  or  more  pairs  of  terms  are  equal,  and  therefore  interchangeable.  Practically  speaking,  however, 
0BJ3  provides  several  built-in  objects  that  make  writing  a  specification  far  easier.  In  addition, 
more  complex  objects  can  be  imported  from  a  library  supplied  with  the  interpreter. 

The  built-in  objects  define  boolean,  integer,  rational,  real,  tuple,  and  string  operations.  Most 
are  implemented  by  Lisp  code  for  efficiency. 

The  library  objects  define  sets,  lists,  arrays,  complex  numbers,  quaternions,  categories,  and 
unification.  A  decision  procedure  for  propositional  calculus  and  a  bubble-sort  algorithm  are  also 
specified  in  0BJ3. 

S.7.4  Formal  System  Basis 

For  a  specification  language  to  support  verification,  it  must  have  a  formal  semantics.  Otherwise, 
theorems  cannot  be  legitimately  proven.  0BJ3  has  both  an  operational  semantics  and  a  mathe¬ 
matical  semantics. 

The  operational  semantics  of  0BJ3  is  based  on  order  sorted  term  rewriting.  Order  sorted  term 
rewriting  defines  the  behavior  of  the  interpreter’s  rewrite-rule  engine. 

The  mathematical  semantics  of  0BJ3  is  based  on  order  sorted  equational  logic.  Order  sorted 
equational  logic  is  a  restricted  form  of  equational  logic  (a  system  with  no  sorts)  and  a  generalized 
form  of  many  sorted  equational  logic  (a  system  with  no  subsorts).  Equational  logic  is  seen  as  too 
permissive,  whereas  many  sorted  equational  logic  is  seen  as  too  restrictive.  This  compromise  has 
several  benefits: 

Air.rug  the  advantages  of  “strong  typing”,  which  of  course  we  call  strong  sorting, 
are:  to  ..^tch  meaningless  expressions  before  they  are  executed;  to  separate  logically  and 
intuitively  distinct  concepts;  to  enhance  readability  by  documenting  these  distinctions; 
and,  when  the  notion  of  subsort  is  added,  to  support  overloading,  coerdoxu,  multiple 
representations,  and  error  handling,  without  the  confusion  found  in  many  programming 
languages  [GW88]. 

Order  sorted  equational  logic  is  a  rigorous  mathematical  theory.  Of  primary  importance, 
however,  is  the  way  in  which  the  sort  of  an  operation  is  determined.  When  an  operation  name 
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is  parsed,  its  sort  is  chosen  to  be  the  smallest  (i.e.,  lowest  in  the  hierarchy)  of  those  possible. 
But  this  choice  may  be  changed  to  a  larger  sort  (i.e.,  higher  in  the  hierarchy),  in  order  to  apply  an 
equation.  Subsorting  sometimes  allows  an  operation  to  be  defined  as  total,  when  it  would  otherwise 
be  necessary  to  define  it  as  partial;  this  greatly  simplifies  the  operation’s  specification  because  it 
does  not  have  to  detect  argument  values  that  are  outside  of  the  intended  domain.  Thus,  error 
handling  is  often  automatic. 

The  formal  semantics  of  an  0BJ3  object  is  an  algebra.  An  algebra  is  a  collection  of  sets  with 
functions  among  them.  An  object’s  sorts  correspond  to  the  algebra’s  sets,  its  constant  operations 
of  each  sort  correspond  to  the  elements  of  each  set,  and  its  other  operations  correspond  to  the 
functions.  Since  0BJ3  is  based  on  order  sorted  eqnational  logic,  the  proof  theory  of  that  formal 
system  applies  directly  to  0BJ3  specifications. 

For  an  object’s  operational  and  formal  semantics  to  agree,  its  formal  semantics  must  be  an 
initial  algebra  [GM83].  An  initial  algebra  is  one  where  every  element  of  every  set  can  be  named 
t^sjng  the  given  functions  (i.e.,  there  is  no  “junh”)  and  all  true  equations  can  be  proven  to  be  true 
nsing  the  given  equations  (i.e.,  there  is  no  "confusion”). 

An  object’s  formal  semantics  is  an  initial  algebra  if  the  object  is  canonical.  An  object  is  canon¬ 
ical  if  it  is  confluent  and  terminating.  An  object  is  confluent  if  the  order  of  equation  application 
does  not  effect  the  result.  An  object  is  terminating  if  every  reduction  terminates. 

For  many  examples  of  interest,  the  rules  of  equational  deduction  are  both  sound  and  complete. 
In  particular,  this  is  true  when  every  sort  contains  at  least  one  constant.  However,  there  are 
important  examples  without  this  property  [GM83]. 

S.7.5  Specification  Checking 

An  0BJ3  specification  can  be  analyzed  in  (at  least)  three  ways.  It  can  be  shown  to  be  free  of 
syntactic  errors,  it  can  be  shown  to  have  desirable  application-independent  properties,  and  it  can 
be  shown  to  have  desirable  application-specific  properties.  The  first  two  classes  of  properties  can 
be  established  by  general-purpose  tools,  which  are  discussed  here.  The  last  class  is  established  by 
verification,  which  is  discussed  later. 

As  the  interpreter  processes  an  object,  it  parses  and  sort-checks  each  equation  according  to 
the  sort,  subsort,  variable,  and  operation  declarations.  Thus,  it  detects  all  syntactic  and  even  some 
obvious  semantic  errors.  Unfortunately,  this  is  the  only  automatic  analysis  currently  avmlable. 

An  important  feature  that  is  missing  from  0BJ3  is  a  tool  for  determining  if  an  object  is 
canonical.  In  general,  this  question  is  undeddable,  but  in  practice  such  a  tool  often  succeeds. 
More  specifically,  two  tools  are  necessary.  The  first  tries  to  prove  that  an  object  is  terminating; 
the  second  that  a  terminating  object  is  confluent.  Usually,  termination  is  obvious  and  requires 
no  proof.  Confluence  can  be  demonstrated  by  the  Knuth-Bendix  completion  procedure  [KB  70]. 
This  procedure  can  even  generate  new  equations  that  make  an  object  confluent.  Unfortunately,  the 
Knuth-Bendix  procedure  does  not  always  terminate. 

The  Knuth-Bendix  procedure  has  been  implemented  for  a  predecessor  of  OBJ3  named  OBJ 
[GogSOj.  Unfortunately,  these  two  languages  are  substantially  different.  Perhaps  a  future  version 
of  OBJ3  will  also  provide  tools  to  help  check  for  termination  and  confluence. 

Another  useful  tool  that  is  not  provided  is  an  automatic  test  generator  [Jal89].  Such  a  tool 
takes  an  object  as  input  and  produces  as  output  an  arbitrarily  large  set  of  terms.  The  terms  are 
produced  in  order  of  increasing  size  so  that  all  operations  are  covered.  These  terms  can  then  be 
reduced  by  the  interpreter  to  test  the  object. 
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5.7.6  Execution  and  Rapid  Prototype  Support 

For  a  ipecification  language  to  support  testing,  debugging,  and  rapid  prototyping,  it  must  be 
executable.  An  interpreter  for  0BJ3  specifications  is  available  from  SRI  International;  it  is  written 
in  Kyoto  Common  Lisp. 

The  interpreter  maintauns  a  collection  of  currently  defined  modules.  A  module  is  either  a 
parameterized  object,  an  instantiated  object,  a  theory,  or  a  view.  Initially,  only  the  built-in  modules 
are  defined.  The  built-in  modules  provide  arithmetic,  logic,  and  string  operations.  By  default,  a 
reduction  is  performed  in  the  context  of  the  most  recently  instantiated  object,  but  the  interpreter 
can  be  instructed  to  reduce  in  the  context  of  any  defined  object 

Commands  are  given  to  the  interpreter  by  typing  them  at  a  prompt.  The  in  command  causes 
a  file  of  commands  to  be  executed.  Such  a  file  can  also  contain  in  commands.  The  ahov  command 
pretty-prints  a  module  or  displays  system-parameter  values.  These  parameters  primarily  control 
the  interpreter’s  verbosity  (e.g.,  reduction  tracing);  they  are  changed  by  the  aet  command.  The 
reduce  command  reduces  a  term.  When  it  finishes,  it  displays  the  result  and  the  number  of  rewrites 
performed. 

In  0BJ3,  input  is  the  term  to  reduce  and  output  is  the  result  of  its  reduction.  This  is  the 
only  form  of  input/output  that  is  provided.  Thus,  rapid  prototyping  of  computational  algorithms 
is  supported,  but  a  rapid  prototype  cannot  demonstrate  a  realistic  user  interface. 

3.7.7  Verification  and  Theorem-Proving  Support 

There  are  three  levels  to  consider  when  using  0BJ3  as  a  theorem  prover.  Only  the  activities  of 
first  level  are  supported  by  the  interpreter.  Activities  of  the  other  two  levels  must  be  performed 
manually. 

At  the  lowest  level  of  verification,  equations  are  applied  to  reduce  terms.  For  a  person,  this 
work  is  tedious  and  error-prone.  Fortunately,  machines  thrive  term  substitution.  Thus  OBJS’s 
rewrite-rule  engine  can  execute  proof  scores. 

At  the  middle  level  of  verification,  these  proof  scores  are  constructed.  A  proof  score  contains 
module  definitions  and  reductions  that  prove  a  theoron.  More  precisely,  the  theorem  is  only  proven 
if  all  the  reductions  reduce  to  true.  For  example,  a  proof  score  might  employ  induction  to  prove 
that  a  property  of  a  particular  specification  always  holds. 

Automatic  construction  of  proof  scores  is  an  attractive  prospect,  especially  if  their  correctness 
is  guaranteed.  One  approach  is  to  supply  a  library  of  generic  proof  scores  that  can  be  instantiated 
as  needed.  Another  approach  is  to  employ  "proof  management"  software  that  understands  proof 
tactics  but  relies  on  OBJ3’s  interpreter  to  do  the  real  work. 

At  the  highest  level  of  verification,  the  correctness  of  proof  scores  is  justified.  Such  justifications 
are  usually  very  abstract  and  cannot  possibly  be  done  mechanically.  The  language  employed  is 
mathematics  (e.g.,  that  of  initial  algebras). 

3.7.8  Low  Water  Mark  Example 

As  a  concrete  demonstration  of  the  OB  J3  language,  this  section  presents  a  specification  of  the  Low 
Water  Mark  security  problem  [CGHM81].  Following  this  specification,  the  security  constraints 
are  formulated  as  an  invariant  and  an  inductive  proof  is  given  that  verifies  that  the  specification 
establishes  and  maintains  the  invariant. 

The  problem  is  to  control  access  to  a  shared  database  containing  a  single  item  of  information. 
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tkaery  ITtK  !■ 

•art  ItM  . 

op  aotfeand  :  •>  Itaa  . 
•adtk 


Figure  1:  The  Requirements  for  a  Database  Item. 

In  accordance  with  access  constraints,  a  user  can  read  the  data  item,  write  a  new  item  into  the 
database  (possibly  lowering  the  database  security  level),  or  reset  the  database  security  level  to  its 
highest  possible  value.  A  reader’s  security  level  must  not  be  lower  than  the  database’s  level  and  a 
writer’s  or  resetter’s  security  level  must  not  be  higher  than  the  database’s  level. 

Rather  than  designing  a  specification  for  a  database  containing  a  particular  sort  of  data,  a  pa- 
rameterued  spedfication  is  constructed.  Only  one  parameter  is  needed,  but  when  the  specification 
is  instantiated  the  parameter  must  supply  a  sort  and  an  element  of  that  sort  to  return  as  the  result 
of  a  successful  read  of  an  initialised  database.  These  requirements  are  specified  by  the  theory  in 
Figure  1.  The  theory  requires  an  instantiating  object  to  supply  a  sort  named  Item  and  a  constant 
of  sort  Item  named  notf  ound. 

The  Low  Water  Mark  specification  is  shown  in  Figure  2.  Capitalixation  clearly  counts  and 
follows  the  recommended  conventions:  Module  and  variable  names  are  all  uppercase.  Sort  names 
are  uppercase  and  lowercase.  Operation  names  and  keywords  are  all  lowercase.  Comments  begin 
with  three  asterisks  and  continue  to  the  end  of  the  line. 

The  first  line  of  LWM  declares  a  parameter  I  that  must  satisfy  the  ITEM  theory.  The  object  then 
declares  two  sorts  named  Database  and  Level,  imports  a  built-in  object  INT,  and  declares  that 
the  integers  are  a  subset  of  the  levels.  Thus,  integers  can  be  used  as  levels.  Sort  Int  is  declared  in 
object  Zirr.  The  names,  arities,  and  coarities  of  the  operations  provided  by  LWM  are  then  declared. 
Operation  ns«  constructs  an  initialized  database  with  a  security  level  of  ten,  the  highest  possible 
value  for  this  specification;  read,  vrite,  and  reset  do  what  their  names  imply;  rd-done,  «r-done, 
and  rs-done  return  the  results  of  read,  vrite,  and  reset  (resp.);  1«b  bundles  a  security  level  with 
a  data  item  to  form  a  database;  high  is  the  highest  security  level;  and  none  is  the  item  returned 
to  writers,  resetters,  and  unauthorized  readers.  Following  this  "signature”  of  LWM,  several  variables 
are  declared  (variable  I  is  distinct  from  parameter  I).  Finally,  equations  specify  the  behavior  of  the 
declared  operations.  The  first  two  construct  an  initialized  database;  the  next  three  do  the  actual 
reading,  writing,  and  resetting  according  to  the  security  constraints;  and  the  last  nine  allow  nested 
invocations  to  interact  appropriately. 

In  order  to  test  the  specification  in  Figure  2,  it  must  be  instantiated.  First,  an  object  must  be 
chosen  as  the  parameter  to  LWM.  Then,  a  view  must  be  used  to  specify  how  that  object  satisfies  the 
ITEM  theory.  And  then,  another  object  must  be  constructed  that  imports  and  instantiates  LWM. 

A  simple  example  is  a  database  of  natural  numbers.  Figure  3  specifies  how  the  built-in  ob¬ 
ject  lAT  satisfies  ITEM.  Sort  Item  is  satisfied  by  (mapped  to)  sort  Mat  and  constant  notf  ound  is 
satisfied  by  (mapped  to)  constant  0.  The  view  ZTEM-TO-IAT  implicitly  imports  ITEM  and  NAT. 
Figure  4  shows  LWM  being  instantiated  according  to  ITEM-TO'IAT.  Sample  reductions  demonstrate 
the  specification’s  operations. 

There  are  three  main  steps  in  verifying  that  LWM  correctly  enforces  the  Low  Water  Mark  security 
constraints.  First,  a  proof  object  is  constructed  from  the  specification  object  in  Figure  2.  The  proof 
object  is  then  instantiated  and  augmented  with  a  predicate  on  sort  Database  that  expresses  the 
security  constraints.  This  predicate  is  then  used  with  a  form  of  structural  induction  [GHM78]  to 
prove  that  the  constraints  are  never  violated. 
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•kjaet  LWICI  <!  XTia]  U 

•art  Batabaaa  . 

••rt  L«*«l  • 
prataetiag  ITT  . 

•■baart  lat  <  Laval  . 

ap  aaa  t  •>  Databaaa  . 
ap  raad  :  Laval  Databaaa  ~>  Databaaa  . 
ap  arlta  :  Laval  Itaa  Databaaa  •>  Databaaa  . 
ap  raaat  :  Laval  Databaaa  ->  Databaaa  . 

ap  rt^aaa  i  Itaa  Databaaa  ->  Databaaa  . 

ap  ar^aaa  <  Itaa  Databaaa  ->  Databaaa  . 

ap  ra>4aBa  i  Itaa  Databaaa  ->  Databaaa  . 

ap  laa  i  Laval  Itaa  •>  Databaaa  . 
ap  bigb  I  ->  Uval  . 

ap  aaaa  i  •>  Itaa  . 

var  L  U  t  Laval  • 
var  I  11  13  I  Itaa  . 

aaa  Craata  a  aaa  4atabaaa. 

aq  aaa  a  laa(blgb.aat<aaad)  . 
aq  kl(h  a  to  . 

aaa  raad  raqairaa  DraeUv  >a  ObJUv;  it  daaa  aat  ebaaga  ObJLav 
aq  raadlLtlaaCLlall))  a 
If  L  >«  LI  tbaa 

rd-deaa < I 1 , laa (L 1 , I 1 ) ) 

alaa 

rd>daaa  <aaaa  •  laa  (U 1 1 1 ) ) 

fi  . 

aaa  arlta  taqairaa  DracLw  <a  ObJUv;  it  aata  ObJUv  ta  DraeUv 
aq  arlta(L.I.laa(Ll.Il))  a 
If  L  <■  LI  tbaa 

vr-daaa(aaaa,laa(Lt I ) > 

alaa 

ar^aaa(aaaa  ,laa(Ll .  XI ) ) 

fl  . 

aaa  raaat  raqairaa  FraeUv  <a  ObJUv;  it  aata  ObJUv  ta  blgb 
aq  raaat (L.laa(Ll, ID)  a 
If  L  <■  LI  tbaa 

ra-daaa  (aaaa ,  laB<bl(b ,  ID ) 

alaa 

ra-daaa(aaBa,laa(Lt >11 )) 

fl  . 


Figure  2:  Tli«  Low  W«ter  Murk  Spedficution  Object  (1  of  2). 


aaa  nialaata  caaplatad  lavacatlaaa. 

aq  raad(L,rd-4aBa(J3.1aBai.Il»)  >  raada.laaOl.Il))  . 
aq  raada.ar-daaa<I3.1fai,Il)))  a  raada.laaOl.ID)  . 
aq  raada.ra-daaa(I3.1aBai.Il»>  •  raada.lvBOl.Il))  . 
aq  arlta(L>Itld*daaa(X3,laB(Ll.Xl)))  ■  arlta<L,I,laB{Ll,Il)>  . 
aq  vrltaa.I.ar-daaadS.laBOl.Il)))  ■  arltaa.I.lMOl.Il))  . 
aq  arltaa.I.tvdaaadS.laaOl.Xl)))  ■  arltaa.I.laaai.ID)  • 
aq  raBat(L.rd-daaad3.1aB(U.Il)»  -  raaat (L.IvbCU. II »  . 
aq  raaat(L>ar-daaad3>la»(Ll>Xl)))  ■  raaat<L>l«(Ll>Il>)  . 
aq  raaata.ra-daaad3.1aa(U.Il)»  a  raaat (L.laBiU. ID)  . 


Figure  2:  Tbe  Low  Wuter  Mork  Specificution  Object  (2  of  2). 
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via*  ITEH-TO-liT  fraa  ITEM  to  lAT  ia 
aart  Itaai  to  lat  . 
ap  aatfaoBd  ta  0  . 

aada 


Figure  3:  Satisfying  the  Item  Requirements. 


abjaet  LMIl  ia 

pratactiac  Lm[ITIII-TO>SAT]  .  aaa  iaataatiata 

aada 

radaea  raad(6.arlta(S. till. aaa))  . 

radaea  raad(d,Brlta(S. lilt. aaa))  . 

radaea  raad(7.arlta(6.3322.raad(9.arlta(S.llll.aaa))))  . 

radaea  raad(S.arlta(6.33}a.raad(«.arita(8.1111.aaa))>)  . 

radaea  raad(7.raaat(e.arita(S,llll.aaa)))  . 

radaea  raad(7,raaat<4,arlta(S.lltl.aaa)))  .  lapVi. 


radaea  la  UMl  i  raad(«.erita($. till. aaa)) 

raarltaai  S 

raaalt  Datakaaa:  rd-daaa(ltll,laB(S.llll)) 


radaea  ia  umi  >  raad<4.arlta(6. 1111, aaa)) 
raarltaai  • 

raaalt  Oatabaaa:  rd'^aaa(aaaa,laB(S,itii)) 


radaea  la  UHl  i  raad(7,arlta(«,n33.raad(9.arlta(8,ltll.aaa))» 
raa-ltaa;  17 

raaalt  Databasai  rd>daaa(2333.1aa(8,3n3)) 


radaea  U  LMl  i  raad(S.arlta(8,3333.raad(9,arita(8.1111.aaa))>) 
raarltaai  17 

raaalt  »atabasai  rd-daaa(aaaa.laa(8.3333)) 


radaea  la  LMl  i  raad(7,raaat<8,arlta(S, till, aaa))) 
raarltaai  13 

raaalt  tatabtaai  rd-deaa(llll,laB<S,llll)) 


radaea  la  LMl  t  raad(r,raaat(4,erlta(S,lIll,aaa))> 
raarltaai  14 

raaalt  •atabaaai  rd-daaa(aaaa,laa(10.1tll))  Qatpst. 

Figure  4:  Instantiating  and  Testing  the  Specification  Object. 
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•bjtct  nu)or>MoL  !• 

prataetlac  TBOTII>VAUIE  . 
pnt«eti»g  BOOL  . 

•p  aif.thaa.alsc.fi  :  Bool  Baal  Baal  •>  Baal 
[atratagp  (1330)  fathar  (t  B  t)  prac  0]  . 
ap  .aaa.  :  Baal  Baal  •>  Baal  [atratagy  (130)  prac  SI]  . 


aa4e 


abjaet  nOOF'TBOTBU  1 1  TtIV]  la 
pratactlag  TBOTB-fAUX  . 
prataetii^  nOOr-BOOL  . 

ap  aif_tkaa_alaa.fl  i  Baal  Bit  Bit  ->  Bit 

Catratagf  (1  3  3  0)  gatkar  (B  B  k)  prac  0]  . 

.  ap  I  Bit  Bit  •>  Baal  latratagjr  (1  3  0)  prac  Si]  . 


akjact  raoor-BBLtI  i  <  TtXf]  ia 
pratactiag  TlDTI-fBUIB  . 
prataetiH  FBOOF-TBSTBCZ]  . 

ap  _<a.  I  Bit  Bit  •>  Baal  [prac  Si]  . 
ap  .<aa.  I  Bit  Bit  •>  Baal  [prac  SI]  . 
ap  _>a_  I  Bit  Bit  •>  Baal  [prac  Si]  . 
ap  _>aa,  i  Bit  Bit  ->  Baal  [prac  SI]  . 


aaSa 


Figure  5:  Signatures  of  Tliree  Proof  Tools. 

An  alternative  approach  is  to  verify  the  parameterized  specification;  thus  any  instantiation  is 
also  verified.  Although  this  technique  has  been  shown  to  be  mathematically  sound  [Gog88],  OBJS’s 
interpreter  cannot  perform  reductions  in  the  context  of  a  parameterized  object.  Therefore,  such  a 
verification  cannot  currently  be  automated. 

In  order  to  formulate  a  predicate  that  captures  the  Low  Water  Mark  security  constraints,  the 
pnxif  object  (and  conceptually,  the  specification  object)  is  modified  to  record  a  small  amount  of 
historical  information.  In  particular,  three  pieces  of  information  are  saved  as  part  of  the  database: 
the  type  of  access  made  by  the  last  successful  invocation,  the  security  level  of  that  invocation, 
and  the  security  level  of  the  database  just  before  that  invocation  succeeded.  With  this  historical 
information  available,  the  predicate  can  be  formulated  as  an  invariant  of  aU  constructable  databases. 

Aside  from  application-dependent  reasons,  like  the  history  maintenance  described  above,  the 
transformation  from  specification  object  to  proof  object  is  necessary  because  OBJ3*s  interpreter 
can  only  reduce  ground  terms.  The  trick  is  to  replace  variables  with  new  operations  called  variable 
opemtions  [GHM78].  Unfortunately,  a  term  containing  variable  operations  does  not  always  reduce 
as  expected.  The  problems  are  caused  by  the  built-in  conditional  and  rdatkmal  operations.  How¬ 
ever,  these  can  be  replaced  by  the  operations  from  PROOF>BOOL,  PROOF-TRUTH,  and  PROOF-REL.  The 
signatures  of  these  objects  are  shown  in  Figure  5. 

The  new  conditional  operation  U  "eager”  whereas -the  oiipnal  is  "lazy”;  its  evaluation  strategy 
causes  aU  of  its  arguments  to  be  reduced  before  the  boolean  condition  is  tested.  The  new  relational 
operations  are  "symbolic”  whereas  the  originals  are  "literal”;  their  equations  can  reduce  them  to 
true  but  never  to  false. 
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Figure  6  shows  the  proof  object.  Operations  rd,  «r,  and  rs  record  history  information  as  the 
last  argument  to  Im.  Operations  avar,  Ivar,  and  ivar  are  variable  operations  that  can  replace 
variables  of  sorts  matching  their  coarities.  Each  variable  operation  has  a  single  integer  argument. 
This  makes  an  infinite  supply  of  variable  replacements  available  (e.g.,  Ivar(O),  Ivar(l),  lvar(2), 
. . . ).  The  proof  tools  are  then  instantiated  for  each  necessary  sort.  The  imported  operations  are 
used  in  the  equations  as  replacements  for  the  built-in  operations. 

The  proof  object  is  just  as  executable  as  the  specification  object.  In  Figure  7,  the  proof  object 
is  instantiated  for  natural  numbers  and  some  sample  terms  are  reduced.  These  tests  are  the  same 
as  those  in  Figure  4.  This  time,  however,  the  results  contain  history  information. 

The  Low  Water  Mark  security  constraints  are  embodied  by  operation  invariant  in  object 
INVARIANT  shown  in  Figure  8.  After  instantiating  the  proof  object,  INVARIANT  defines  invariant  as 
a  predicate  on  databases  and  instantiates  a  case-analysis  rule  for  it.  Case  analysis  is  a  second-order 
axiom  [GHM78]  that  is  instantiated  as  a  module  expression.  This  particular  expression  imports 
PROOF-CASE  from  Figure  9  and  renames  sort  Sort  to  Database  and  operation  p  to  invariant.  The 
three  equations  for  invariant  cover  each  of  the  three  possible  types  of  database  access.  Variable 
P  represents  the  process  (user)  security  level.  Variable  0  represents  to  object  (database)  security 
level. 

With  the  invariant  specified,  a  proof  score  employing  structural  induction  can  be  constructed. 
The  score  is  shown  in  Figure  10.  The  basis  proves  that  the  invariant  holds  for  an  initialized  database. 
An  object  is  then  used  to  make  an  inductive  hypothesis.  Object  INDUCTION  imports  INVARIANT  and 
(transitively)  the  instantiated  proof  object.  An  equation  then  assumes  that  the  invariant  holds  for 
a  particular  database.  Variable  operations  are  required  here.  With  variables,  the  equation  assumes 
that  the  invariant  holds  for  all  databases,  but  that  is  the  theorem  to  prove.  The  new  equations  for 
rd-done,  vr-done,  and  ra-done  eliminate  completed  invocations,  thereby  allowing  invariant  to 
be  evaluated.  Three  reductions  are  necessary  for  the  inductive  step.  Each  reduction  proves  that  the 
invariant  is  preserved  across  a  particular  kind  of  access,  whether  it  succeeds  or  not.  The  detailed 
trace  of  each  reduction  is  about  two  pages  long.  The  traces  demonstrate  that  the  automatic  proof 
proceeds  essentially  as  a  manual  proof  would. 

S.7.9  Criticsd  Remvks 

The  previous  sections  simply  describe  OBJ3,  this  section  tries  to  gauge  its  suitability  and  effective¬ 
ness  as  a  specification  and  verification  system.  Both  the  language  and  its  interpreter  are  considered. 
Language  deficiencies  are  probably  permanent,  since  correcting  them  probably  requires  changing 
the  underlying  formal  system.  Interpreter  deficiencies  are  not  so  serious;  fixing  them  just  takes 
time. 

Perhaps  the  most  important  characteristic  of  OBJ3  specifications  is  that  they  are  easy  to 
design,  understand,  and  modify.  To  some  extent,  this  is  a  characteristic  of  specifications  written  in 
any  equational  language.  This  clarity  results  from  the  simplicity  of  equational  logic,  where  there 
are  no  sophisticated  built-in  operations  or  complicated  models  of  computation.  There  is  only  one 
rule:  a  term  may  be  replaced  by  an  equal  term.  Of  course,  it  is  a  waste  of  time  to  start  every 
specification  from  scratch;  libraries  of  specifications  are  developed  and  imported  as  needed. 

Equational  languages  are  functional  languages.  As  such,  they  lack  what  programmers  who  use 
conventional  (imperative)  languages  take  for  granted  —  and  have  a  hard  time  giving  up.  Namely, 
a  function  can  only  return  a  single  value,  there  is  no  global  state,  and  there  are  no  assignment 
statements.  But  it  is  exactly  these  familiar  'features"  that  are  responsible  for  most  software 
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•kjaet  UHCl  : :  ZTCH]  is 

ssrt  Ostsbass  . 
ssrt  Lsvsl  . 
ssrt  Aetiss  . 
prstsetisg  XIT  . 
sabsort  lat  <  Lsssl  . 

sp  ass  i  ->  Databass  . 
ap  raad  :  Lssal  Batabasa  ->  Batabasa  . 
ap  aiita  t  Laval  Itaa  Batabasa  ->  Batabasa  . 
sp  rasst  t  Laval  Batabasa  ->  Batabasa  . 

sp  r4>4aas  i  Itaa  Batabasa  ->  Batabasa  . 

sp  sr^aaa  i  Itaa  Batabasa  •>  Batabasa  . 

ap  rs-Saaa  >  Itaa  Batabasa  ->  Batabasa  . 

ap  laa  :  Laval  Itaa  Actiaa  •>  Databaaa  . 

sp  high  I  •>  Laval  . 
sp  Bsaa  :  •>  Itaa  . 

aps  rd  vr  ra  s  Laval  Laval  •>  ictias  . 

•••  Variabla  aparatiaas. 

ap  avar  :  lat  •>  Aetiea  . 
ap  Ivar  i  lat  •>  Laval  . 
ap  ivar  i  lat  •>  Itaa  . 

aaa  Praaf  taals. 

prataetiag  nOOF-TIVniCDatabasa]  . 
pratactiag  PUOr-TtVTiaaval]  ■ 
prataetiag  PUOr-ULCLaval]  . 
pratactiag  PUOF-TBUTlIUetisa}  . 

var  L  LI  :  Laval  . 
var  I  Zi  13  :  Itaa  . 
var  A  :  Actiaa  . 

•••  Craata  a  aav  Satabasa. 

aq  aaa  a  iaa(higb,asttsaB4,rs(bigh,kigh))  . 

sq  bigh  a  10  . 

aaa  raad  raqairas  BraeLav  >a  ObJLav;  it  daas  aat  ebaaga  ObjLav 
sq  raa4(L,lsa(Ll.Ii.A))  ■ 
aif  L  >sa  Li  tbaa 

M-daaadi  ,laB(U  .It  .r4a.U) ) ) 

alas 

rd-daaa<asBs,ln(Ll  ,11  ,A)  > 

fi  . 

aaa  arlta  raqairas  PrscLsv  <a  ObJLavi  it  sats  ObjLav  ta  BrscLav 

Figure  6:  The  Low  Water  Mark  Proof  Object  (1  of  2). 
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>rita(L,l.ln(Ll,Il,A>)  ■ 

•if  L  <•■  LI  than 

•r-doa«  (••■!•.  1*b(L,  I. srCLtLl))) 

•r-don«(nen«,laa(Ll ,11 ,A) ) 

fi  . 

•••  r«>*t  raqniraa  ProcLav  <■  ObJLav;  it  aata  ObjLa*  ta  high 
rasat(L,laB(Ll,Il,A>)  ■ 

•if  L  <•■  LI  than 

ra-doaa(aana,lM(high,Il  ,rs(L,Ll) )) 

•laa 

ra-daaa(aaaa,laB(Ll ,11 ,1> ) 

fi  . 

•••  niaiaata  eaaplatad  lavaeatiaaa. 

•4  raada.rd-daaa(13.1aB(Ll.ll.A)))  -  raad(L.laB(U.Il.A))  . 

•4  raada.ar-daaadS.lBBai.Il.A)))  -  raada.lM(U.ll.A))  . 

•4  raada,ra-daaa(I3.1aB(Ll.Il.A)))  -  raad(L.lnB<U.tl.A))  . 

•4  •rltaa.I.id*daaa(12.1aa<Ll.Il.A»)  -  arltaa.l.laaCLl.ll.A))  . 

•4  aritaa.I.ar-daaada.lBBai.ll.A)))  a  arltaa.I.liBtLl.ll.A))  . 

•4  arltaa.l.ra-daaadS.laBai.ll.A)))  -  aritaa.I.laB(Ll.Il.A>)  . 

•4  raaat(L,rd-daaad3,laB<Ll,Xl,A)))  ■  raaat(L,laa(Ll,ll,A)>  . 

•4  raaat(L,ar-daaad3,laB(Ll,li,A)))  ■  raaat(L.LaB(Ll,ll,A)>  . 

•4  raaat(L,ra-doaad3,laB(Ll,ll,A)))  •  raaat(L,laB(Ll,ll,A) >  . 

•ado 


Figure  6:  The  Low  Water  Mark  Proof  Object  (2  of  2). 


•bjaet  LIffll  ia 

prataetiag  LWCITDI-TO-IAT]  .  •••  iaataatiata 

•ada 

radaea  raad(e,arlta<S,ltll,aa«))  . 
radaea  raad(4,«rlta<6,llll,aaa))  . 

radaea  raad(7,arita(4,3333,raad(9.arita(S,llll.aaa>>))  . 
radaea  raad(5,arita(6, 3333, raad(9,arita(S, 1111, aaa)>)>  . 
radaea  raad(7,raaat(6,arita(S,llll,aaa)))  . 
radaea  raad(7,raaat<4,Brita\:,llll,aaa))>  .  Ippat. 


radaea  la  LWIl  :  raad(6,arita<5,llll,aaa)) 
raarltaa:  11 

raaalt  Satabaaai  rd-daaa(llll,laB(S,llll,rd(6,S))) 


radaea  ia  LHHl  i  raad(4,arita(B,lltl,aaa)) 
raarltaa:  11 

raaalt  Oatabaaa:  rd-daaa(aaaa,laB(S,llll,ar(B,10)>) 


radaea  la  LtfHl  t  raad(7,arlta(6, 3333, raad(9,arlta(8, lilt, aaa))}> 
raarltaa:  19 

raaalt  Databaaai  rd-daaa(3333,laB(6,3333,rd(7,4))) 


radaea  la  Lmi  i  raad(B,arlta(e,2333,raad(9,arlta<9,ltll.aaa)>)) 
raarltaa:  19 

raaalt  Oatabaaa:  rd-daaa(aaaa,laB(6,3333,ar<6,9))) 


radaea  la  LWIl  t  raad(7,raaat(4,arlta(S,llll,aaa))) 
raarltaa:  IS 

raaalt  Oatabaaa:  rd'-daaa(llll,laB(S,llll,rd(7,S)>) 


radaea  la  LWIl  i  raad<7,raaat<4,arlta(B,llll,aaa)>> 
raarltaa:  19 

raaalt  Oatabaaa:  rd>daaa(aaaa,laB(10,llll,ra<4,B)^%^;  Oatpnt. 

Figure  7:  Initantiatisg  and  Testing  the  Proof  Object. 
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•bj«et  IIVUIAIT  is 

•sUc  UmClTEH-TO-IAT]  . 

sss  Prsof  tssla. 

•p  iavsrisat  >  Batabasa  ->  Boai  . 

uiB(  ra00P>CASE  •  (sart  Sort  ta  Oatabasa,  op  p  to  isaariaat)  . 

aaa  Lao  oatar  Mark  iaaariaat. 

aar  I  i  Bat  . 
aar  L  B  0  t  Laaal  . 

a^  iaaariaat(laa(L.X.rS(r.O)))  -  (P  >oa  0  aa4  L  >#■  0>  >o-  traa  . 

oq  iaaariaat<lBB(L.I,ar<P,0>))  ■  (P  <aa  0  aad  L  P)  aaa  traa  . 

aq  iaaariaat (laB(L,X>rs(P,a)))  a  (p  tsa  o  aad  L  aoa  blgh)  aaa  traa  . 

oado 


Figure  8:  The  Low  Water  Mark  Invariant. 


abjaet  PtOOP-CASS  la 
sart  Sart  . 

ap  p  :  Sart  ->  BaoX  . 

op  aif_tboa.alsa.fl  :  Bool  Sort  Sart  •>  Sart  . 
ap  aif_tbaa.alsa.fl  :  Baal  Baal  Baal  ->  Baal  . 

aar  B  :  Baal  . 

aar  SI  S3  i  Sart  . 

a^  p(aif  B  tbaa  SI  also  S3  fl)  - 
aif  B  tbaa 

p(Sl) 

alas 

p<S3) 

fl  . 

oada 


Figure  9:  The  Case- Analysis  Proof  Tool. 
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•••  kuis 


radac*  iaTariuit(B*>)  . 

•••  ladaetl**  kypothaais 

abjaet  inocTIOl  is 
atiag  inuiirr  . 
aar  I  :  lat  . 

aar  D  :  Databasa  . 

aq  lBaarlaat(lSB(laar(l),iaar(l).saar(0)))  a  traa  . 

aq  rd-daaad.D)  ■  0  . 

aq  Br-daBa(l,D)  ■  D  . 

aq  rs-daaad.D)  ■  0  . 

aade 

Xadaetiaa  ataps 


radaea  iaaariaat(raaddaar(0),lSBdaard)|iaar(i),Baar(O)>))  . 
radaea  iaaarlaBt(sritadaar<0>,iaar(0>,laBdaard),i*ar(l),aaar(0))))  . 
radaea  iaaariaat(rasatdaar(0),lsBdaard),iaar(l)^t^afl^|^.)  . 


radaea  ia  IIVAIIAtT  i 
raarltas:  10 
rasalt  kael:  traa 

1  laaarlaat<aaa) 

abjaet  IIDUCTIOI 

radaea  la  IIDOCTIOI  •. 

0)))) 

raarltas:  11 
rasalt  •sal:  traa 

:  lBaariaBt(rasd(laar(0>,laB(lTar(l),iaar(l) ,aaar( 

radaea  la  JIDVCTIOI  : 

l),avBr(0))>) 
raarltas:  11 
rasalt  Baal:  traa 

1  laaarlaat  (arlta  (laar  (0)  ,laar(0)  .IsBdaard  )  ,laar  ( 

radaea  la  IIDOCTIOI  : 
0)))) 

raarltas:  13 
rasalt  Iasi:  traa 

:  laaarlaat (rssat (laar (0),laa(laar(l), laar <l>,Baar( 

(b):  Oatpat. 

Figure  10:  VeriAcatioa  of  the  lawiant  by  Induction. 
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defects. 

As  advertised,  0BJ3’s  sort  tyttem  is  a  realistic  coxapromise  between  anarchy  and  tyranny. 
Probably  the  best  way  to  make  a  specification  understandable  is  to  use  mnemonic  sort  names  from 
the  problem  domain.  A  strict  sort  system  also  helps  to  promote  a  disciplined  style  of  specification. 
Nevertheless,  subsorting,  overloading,  and  coercion  relax  many  of  the  unnecessary  restrictions  found 
in  typical  systems.  Overloading  is  also  heavily  relied  upon  for  defining  proof  tools  for  the  example 
verification. 

0BJ3’s  parameterixation  mechanisms  are  more  powerful  than  those  found  in  any  other  lan¬ 
guage.  Theories,  views,  and  module  expressions  allow  very  generic  specification  libraries  to  be 
developed  and  reused.  Even  on  its  own,  this  sublanguage  is  worthy  of  merit.  The  sublanguage,  and 
the  programming  paradigm  it  supports,  promotes  and  enforces  hierarchical  and  modular  designs. 

Even  though  0BJ3  does  not  come  with  a  conventional  theorem  prover,  its  interpreter  can 
do  much  of  what  a  theorem  prover  is  supposed  to  do.  This  leads  to  an  interactive  style  of  proof 
development  that  is  pragmatic,  intuitive,  and  subject  to  user  control.  In  addition,  a  failed  proof 
attempt  often  suggests  corrections  or  lemmas  by  providing  a  readable  trace  of  the  failed  attempt. 
Reading  such  a  trace  really  is  the  best  way  to  debug  a  proof;  provers  that  report  only  ‘‘proved”  or 
“unproved”  provide  no  such  help.  In  contrast  to  this  interactive  approach,  fully  automatic  provers 
are  sometimes  difficult  to  steer,  while  fully  manual  provers  require  a  user  to  perform  too  much 
tedious  work. 

As  is,  the  interpreter  provides  only  rudimentary  verification  support.  Therefore,  several  im¬ 
provements  should  be  incorporated.  Some  of  these  improvements  are  already  available  in  the  Affirm 
specification  and  verification  system  [TE81].  Alternatively,  Affirm  would  benefit  by  integrating 
some  of  0BJ3’s  features. 

The  rewrite-rule  engine  should  be  modified  to  enable  it  to  reduce  terms  containing  variables. 
These  variables  could  be  treated  (internally)  as  variable  operatioxu.  Hence,  full  unification  is 
unnecessary.  Affirm  provides  this  capability. 

The  rewrite- rule  engine  should  also  be  modified  to  accept  recursion-limiting  commands.  These 
commands  are  often  needed  during  verification  because  recursive  equations  cause  nonterminating 
reductions  during  a  proof.  Such  equations  occur  naturally,  but  they  also  result  when  a  conditional 
equation  is  transformed  into  a  regular  equation.  This  transformation  is  also  necessary  for  verifica¬ 
tion  and  should  be  automated.  Affirm  provides  a  restricted  form  of  recursion  limiting.  Namely,  it 
offers  one-level  rewriting. 

A>verification  interface  should  also  be  added  to  the  system.  This  could  be  a  separate  tool  for 
constructing  proof  scores,  or  a  shell  that  understands  proof  strategies  and  manages  a  proof  attempt. 
Affirm  allows  executable  “proof  schemas”  to  be  defined  and  provides  a  tree-based  proof  manager. 

Tools  that  help  prove  that  an  object  is  canonical  are  also  needed.  Thus,  an  order-sorted  version 
of  the  Knnth-Bendix  completion  procedure  should  be  implemented.  This  should  be  provided  as  a 
separate  tool.  Affirm  includes  an  implementation  of  the  procedure,  but  insists  that  all  specifications 
be  canonical.  It  generates  and  adds  completion  equations  while  a  specification  is  being  input.  This 
approach  seems  clumsy  and  dogmatic. 

All  in  all,  0BJ3’s  interpreter  is  quite  efficient  and  relatively  bug  free.  Error  messages  are 
generally  informative,  but  sometimes  they  try  to  be  more  helpful  than  they  are.  For  example,  if 
the  parser  cannot  decide  between  two  parses  it  tries  to  print  both  possibilities,  but  they  are  often 
indistinguishable.  At  least  it  tries  to  be  helpful.  The  interpreter  also  provides  easy  access  to  the 
underlying  Lisp  interpreter.  0BJ3  purists  may  shudder,  but  this  is  a  very  important  feature. 

Even  though  the  interpreter  is  intended  to  be  run  in  an  Emacs  (Sta87]  window,  the  user 
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interface  could  be  improved.  For  example,  command-history  and  command-completion  mechanisms 
would  be  convement.  There  should  also  be  a  command  to  change  what  the  interpreter  considers  as 
the  “current  directory"  for  in  commands.  It  should  also  change  the  current  directory  while  reading 
a  file,  so  that  nested  in  commands  work  as  expected. 

The  reference  manual  is  complete  and  well  written.  It  describes  the  language,  its  extensive  and 
interesting  history,  its  operational  and  mathematical  semantics,  and  explains  many  examples.  A 
large  bibliography  is  also  provided.  The  Lisp  code  itself  is  also  well  organized  and  well  documented. 
The  value  of  this  latter  feature  should  not  be  underestimated. 
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3.8  EVES 

5.8.1  Overview 

EVES  is  an  environinent  for  coding  verified  programs  being  developed  at  I.P.  Sharp  Associates 
Limited,  Ottawa.  The  aim  of  the  project  is  a  production  quality  verification  system  for  programs 
satisfying  NCSC  A1+  requirements.  The  system  was  also  required  to  have  a  rigorous  proof  of  sound¬ 
ness,  the  designer’s  contention  being  that  many  theorem  provers  in  existence  embodied  primitive 
and  unsound  concepts. 

The  method  of  proof  consists  in  incrementally  entering  definitions  of  sjrmbols  and  satisfying 
certain  proof  obligations  indicated  by  the  system. 

The  research  can  be  divided  into  two  main  components;  Verdi  which  is  the  language  for 
specification  and  implementation  (embodying  the  mathematical  basis)  and  NEVER,  the  theorem 
prover  developed  for  constructs  in  Verdi. 

The  approach  has  been  to  construct  a  prototype  system  -  m-EV£S,  divided  into  m- Verdi  and 
m*NEVEE  -  and  augment  it  to  achieve  the  necessary  power  of  EVES.  Thus  m-EVES  provides  an 
environment  for  research  and  instruction.  It  has  been  completed  at  the  end  of  1987,  and  work  has 
continued  since  then  towards  the  production  quality  EVES  system.  A  fairly  large  proof  regarding 
the  Low  Water  Mark  example  has  been  published  in  [CKM*88]. 

3.8.2  Execution  and  Rapid  Prototype  Support 

The  language  for  specification  and  implementation  (m- Verdi)  includes  many  common  programming 
features,  based  on  Pascal-like  constructs.  It  is  a  strongly-typed  Umguage,  and  presents  constructs 
for  annotations. 

Communication  with  the  devices  which  affect  the  program  and  which  may  be  affected  by 
it  is  provided  by  the  environment,  which  introduces  symbols  and  captures  concepts  forming  an 
axiomatic  basis  for  the  program. 

A  compiler  for  m- Verdi  already  exists;  it  has  been  developed  using  the  Karlsruhe  Code  Gen¬ 
erator  Synthesis  System.  Programs  in  m-Ver<fi  are  compiled  into  code  for  VAX  machines.  The 
compilerincorporates  several  optimizatioiu,  and  it  is  also  easily  retargetable  to  other  systems. 

8.8.3  Abstraction  Mechanisms 

Abstraction  and  information  hiding  is  provided  in  m- Verdi  through  the  use  of  a  package  construct. 
Packages  collect  together  a  sequence  of  declarations.  Some  symbols  may  be  hidden  from  the  rest 
of  the  program,  as  well  as  the  body  of  the  package. 

Packages  are  interesting  in  that  they  allow  proofs  to  be  deferred:  while  for  other  entities  the 
proof  obligations  must  be  satisfied  at  the  time  they  are  b^g  declared,  a  package  header  may 
be  declared  and  used  while  the  body  of  the  package  may  be  added  later,  at  which  time  the  proof 
obligations  must  be  satisfied.  To  avoid  drcnlahty,  proofs  for  mnst  use  the  state  *vi»tiTig  immediately 
after  the  declaration  is  given. 

3.8.4  Forms  of  Logic  Supported 

The  logic  behind  EVES  is  based  on  Predicate  Calculus,  with  extensions  to  allow  for  definition  of 
recursive  functions  and  introduction  of  new  symbols. 
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Proofs  in  EVES  consist  of  extensions  to  &  theory  -  a  set  of  symbols  (the  vocabulary)  along 
with  a  set  of  axioms  relating  the  symbols.  Extensions  to  a  theory  are  conservative,  in  the  sense 
that  meanings  of  symbols  existing  prior  to  the  extension  do  not  change.  This  is  explained  in  more 
detain  in  [Cra87]. 

5.8.5  Verification  and  Theorem  Proving  Supported 

The  theorem  proving  style  is  based  on  the  following  components  of  the  system: 

•  a  simplifier:  nses  tautology  checking,  congruence  closure,  and  linear  programming  techniques; 

•  a  rewriter:  supports  conditional  rewriting  with  backchaining,  forward  rules,  and  rules  allowing 
permuted  parameters; 

•  an  invoker:  conditionally  expands  function  definitions  based  on  heuristics; 

•  induction:  based  on  the  Boyer>Moore  method  for  automatic  induction. 

The  m- NEVER  theorem  prover  allows  for  interactive  development  of  proofs  coupled  to  powerful 
automatic  capabilities.  The  system  allows  easy  transition  from  a  proof>checking  mode,  with  user 
input  guiding  the  proof,  to  a  largely  automatic  method,  by  invoking  commands  which  allow  the 
system  to  use  more  and  more  heuristics.  Large  proof  steps  can  thus  be  obtained. 

5.8.6  Specification  Checking — Completeness,  Consistency,  and  Soundness 

Specifications  in  m- Verdi  are  based  on  the  Floyd-Hoare  style,  using  pre-  and  post-assertions.  Heuris¬ 
tic  information  can  be  linked  to  prepositions. 

Any  symbol  must  be  declared  before  being  used.  Proof  obligations  must  be  satisfied  before  a 
symbol  can  become  part  of  the  vocabulary.  This  ensures  soundness. 

All  declarations  are  syntactically  and  semanticaUy  checked  by  the  system.  Recursive  proce¬ 
dures  must  be  well  defined,  and  procedtires’  verification  conditions  must  be  proved.  A  procedure 
must  be  proved  to  terminate  as  well  as  to  satisfy  the  post-condition. 

3.8. 7  Formal  System  Basis — Completeness,  Consistency,  and  Soundness 

The  basis  of  EVES  is  the  many-sorted  predicate  calculus,  which  provides  a  rigorous  mathematical 
characterization.  The  semantics  of  the  m- Verdi  language  is  based  on  Denotational  Semantics.  The 
logic  has  been  shown  to  be  sound  relative  to  the  formal  semantics. 

Note  that  this  does  not  imply  that  any  proof  obtained  using  the  m-EVES  system  is  correct, 
as  there  is  no  proof  yet  of  the  correctness  of  the  implementation  of  m-EVES.  There  is  still  work  to 
be  done  in  obtaining  a  proven  **proof-checker”  for  proofs  obtained  through  m-EVES. 

3.8.8  Examples 

As  a  demonstration  of  the  use  of  m-EVES,  we  will  show  parts  of  the  verification  of  a  mathe¬ 
matical  algorithm:  exponentiation  using  the  fact  that  x*  —  for  even  y.  This  proof  has  been 

obtained  from  [Cra88]. 

The  declaration  of  the  procedure  which  embodies  this  algorithm  is  given  in  Fig.l.  Before  this 
procedure  can  be  added  to  the  theory,  the  auxiliary  function  EXP  must  be  defined,  and  several 
properties  of  DIV  must  be  axiomatized. 
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iprocadura  FAST.EXPOIEITIATIOI  (pvar  Z. 

pvar  T.  pvar  &ESOLT)  * 

iaitial  (Z>0  -  Z,  T>0  >  T) 
pest  HESULT  a  EZP  (Z*0,  T*0) 
bagia 

USULT  :«  1 
loop 

iavariaat  AID  (Z1T*6£  (T.  0). 

TZRES  (IESDLT.  tZP  (Z.  T))  ■  EZP  (Z>0,  T.O)) 
aaasara  OBOZIAL'VAL  (T) 
exit  «haa  T  ■  0 
11  MOD  (T.  2)  a  0 
thaa  Z  :a  TINES  (Z,  Z) 

T  :a  DIV  (Y.  2) 

else  lESULT  :a  TIMES  (Z.  RESULT) 

T  :a  MIIUS  (Y.  1) 

aad  if 
aad  loop 

aad  FAST.EZPOIEITIATIOI; 


Figure  1:  Procedure  for  exponeutiatioa. 


ifaaetiea  EZP  (Z,  Y):  IIT  a 
pra  IIT'GE  (Y,  0) 

•aasara  OIDIIAL'VAL  (Y) 
bagia 

if  Y  a  0  tbaa  1 

alsa  TINES  (Z.  EZP  (X,  MHOS  (Y.  1))) 

aad  if 
ead  EZP; 


Figure  2:  Function  describing  exponentiation. 
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Baginning  proof  of  EXP . . . 

IMPLIES  (AID  (Y  <>  0, 

IIT'CE  (Y.  0)). 

ORDIIAL'LT  (OROIIAL'VAL  (NIIUS  (Y.  1)). 
OROIIAL'VAL  (Y))) 


iroduca; 

Which  aiaplifiaa 

«han  rawritiag  vith  ORDIIAL'LT.d  to  . . . 
TRUE 


Figure  3:  Proof  of  function  EXP. 

The  body  of  EXP  U  ihown  in  Fig.2.  As  this  is  n  recursive  function,  EVES  requires  n  proof  th&t 
it  terminates.  This  is  done  by  showing  that  the  measure  expression  (in  this  case  ORDIMAL'VAL  (Y) 
strictly  decreases. 

When  the  body  of  EXP  is  entered,  the  system  shows  what  proof  obligations  should  be  fulfilled, 
as  shown  in  Fig.3.  The  only  resulting  obligation  is  completed  by  the  simple  rule  reduce. 

For  the  proof  of  FAST.EXPONENTZATION  it  is  useful  to  add  IHT'GE  (DIV  (X.  Y) .  0}  as  an 
assumption;  this  can  be  obtained  by  applying  a  forward  rule  (FKULE)  to  a  proposition  which  contains 
DIV  (X,Y).  The  declaration  of  this  axiom,  as  well  as  the  satisfaction  of  its  obligations,  is  shown  in 
Fig.4. 

Note  that,  as  with  the  Boyer-Moore  prover,  this  system  attempts  to  complete  the  proof  through 
simplifications  before  invoking  induction,  and  it  finds  the  induction  scheme  automatically.  The 
transcript  has  been  simplified  to  show  only  salient  points. 

A  few  more  axioms  have  been  used  for  the  proof;  these  will  not  be  shown  here.  When  the 
declaration  of  FAST.EXPONENTIATIOK  is  finally  added,  the  proof  obligation  is  satisfied  by  a  simple 
application  of  reduction. 

S.8.9  Critical  Remsirks 

The  EVES  system  has  achieved  substantial  success  in  obtaining  verified  and  executable  programs. 
The  notation  used  is  rich  enough  to  express  seve.'al  non-trivial  programs  smd  to  write  relevant 
specifications  and  propositions.  Because  of  the  origins  of  m- Verdi  in  programming  languages  such 
as  Pascal,  expressing  programs  in  this  language  is  quite  natural. 

The  language  however  does  not  have  any  constructs  to  express  concurrency,  and  neither  is 
there  an  inclusion  of  polymorphism  or  higher>order  functions  (though  these  might  be  included  in 
the  final  version  of  EVES). 

It  is  also  important  to  remember  that  the  correctness  of  the  implementation  has  not  been 
proved.  This  correctness  is  quite  essential  in  a  system  of  the  sise  of  EVES,  which  incorporates 
many  different  rewrite  tools  and  heuristic  methods  (i.e.  there  is  a  lot  of  code  which  must  be 
trusted). 
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•uioa  DIV.IOIIEGATIVE  (Z.  T)  > 
FULE 

triggars  (DZV  (Z.  T)) 

b«gia  ZKFLZES  (AID  (ZIT'GE  (Z.  0). 

IIT'CE  (T,  0)) 
IIT'CE  (OIV  (X,  T). 
•ad  SZT_I0IIE6ATZVE: 

Bffgiaaiag  proof  of  IQIIEGATIVE  . . . 
ZNPUES  (AID  (ZIT>6£  (Z,  0), 

IIT'GE  (Y.  0)). 

IIT'GE  (DIV  (Z.  T).  0)) 


iprovt  by  iaduetion; 
Hbieb  siaplif i«a  to  . . . 


latoraiag  to  : 

Bogiaaiag  proof  of  OIV.IOIIEGATIVE  . 
Zadaetiag  aaiag  th«  follovxag  acbm* 


prodaeaa  . . . 


Vhicb  aiapllfiaa 

•itb  Aavoeatioa  of  OIV  to  . . . 

TVIE 


0)) 


Figor*  4:  Proof  of  as  axiom  about  DIV. 


3.9  Gypsy 
S.0.1  Overview 

Gypsy  is  an  integrated  system  of  methods  for  formal  program  specification,  implementation  and 
verification.  It  provides  precise  means  of  expressing  a  program  throughout  all  stages  of  its  design 
from  initial  formal  specification,  implementation,  verification,  to  subsequent  evolution.  Gypsy 
also  provides  modularity,  incremental  development,  abstract  data  types,  and  support  for  process 
concurrency  which  includes  synchronizing  process  communication  and  real-time  dependencies. 

S.9.2  Execution  and  Rapid  Prototype  Support 

The  environment  for  Gypsy  is  called  the  Gypsy  Verification  Environment  (GVE).  This  environment 
is  currently  run  on  Symbolics  3600  and  MULTICS.  The  two  general  services  of  the  environment 
are  maintaining  library  and  providing  tools.  It  maintains  in  database  a  library  of  Gypsy  pro¬ 
gram,  specification,  and  verification  condition,  etc..  It  also  provides  the  tools  for  implementing  the 
specification,  programming,  and  verification  methods. 

The  GVE  contains  several  major  subsystems  to  support  the  development  and  verification  of 
programs :  a  Gypsy  database  manager,  a  parser,  an  edit  interface,  a  verification  condition  generator, 
a  theorem  prover,  a  program  optimizer,  a  Bliss  translator,  and  an  Ada  translator.  In  addition  to 
all  these,  G)rpsy  has  an  overall  top  level  executive  which  monitors  the  verification  status  of  all  units 
in  the  database  and  guides  the  user  through  the  verification  process. 

S.9.S  Abstraction  Mechanisms 

Gypsy  is  derived  from  Pascal.  However,  some  of  the  rules  in  Pascal  has  been  changed  in  order  to 
simplify  the  verification  processes.  Gypsy  does  not  allow  nested  routines,  variable  parameters,  or 
routines  as  parameters  to  other  routines.  This  eliminates  any  side  effects  that  may  happen,  thus 
simplifies  verification  and  increases  the  potential  for  optimization  of  expression  evaluation. 

Gypsy  has  the  features  that  support  unit-by-unit  manipulation,  increase  unit  independence, 
and  isolated  unit  interactions.  The  Independent  Principle  in  Gypsy  says  that  "the  proof  of  a 
routine  may  only  depend  upon  its  own  specifications  and  implementation,  and  upon  the  external 
specifications  of  the  routines  to  which  it  textually  refers”.  The  Independent  Principle  insures  that 
the  implementation  of  one  routine  cannot  interfere  with  the  proof  of  any  other  routine. 

5.9.4  Forms  of  Logic  Supported 

The  verification  in  Gypsy  can  be  done  by  formal  proof,  by  run  time  validation,  or  they  may  simply 
be  assumed.  Specification  that  are  proved  or  assumed  need  not  be  evaluated  at  run  time,  and 
therefore  they  are  permitted  to  contain  special  operations  and  types  that  could  not  otherwise  be 
permitted. 

5.9.5  Verification  and  Theorem  Proving  Support 

There  is  a  Theorem  Prover  in  the  Gypsy  verification  system  which  interactively  assists  in  proving 
the  verification  conditions.  The  Theorem  Prover  is  mostly  interactive  and  has  commands  that 
attempt  to  complete  a  proof  automatically.  It  is  a  tool  that  is  easy  to  guide  through  a  proof  and 
easy  to  follow.  It  can  also  display  a  "proof  tree”  which  shows  the  steps  of  the  proof. 
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5.9.6  Specification  Checking 

Is  Gypsy,  it  is  possible  to  give  formal,  mathematical  proofs  that  a  program  satisfies  its  specifications. 
The  Verification  Condition  Generator  in  Gypsy  is  designed  so  that  it  is  always  possible  to  construct 
antomatically  a  set  of  theorems  (verification  conditions),  that  are  sufficient  to  prove  the  consistency 
of  a  program’s  implementation  and  its  specifications.  If  these  formulas  can  be  proved,  then  whenever 
the  program  runs,  its  implementation  causes  an  effect  that  satisfies  its  specifications. 

5.9.7  Support  and/or  Adaptability  for  Concurrency 

Gypsy  also  allows  both  the  specification  and  the  coding  of  concurrent  processes.  The  process  in 
Gypsy  is  the  same  as  the  procedure  except  that  it  only  allows  message  buffer  as  parameter. 

Message  buffer  is  a  finite  length  queue  in  which  there  arc  only  two  operations:  send  (enqueue) 
and  receive  (dequeue).  The  buffer  uses  a  straight  first  in  first  out  algorithm  and  all  the  operations 
are  mutually  excluded  in  time. 

The  communication  between  the  processes  in  Gypsy  is  done  straightly  through  message  buffer. 
Buffer  in  Gypsy  is  a  predefined  structure,  it  may  be  declared  locally  or  passed  as  parameter. 
Gypsy  keeps  a  history  of  all  the  transactions  that  are  performed  to  a  buffer.  The  send  and  receive 
statements  append  the  transaction  to  the  appropriate  local  history  with  the  time  of  transaction 
stamped  on  the  record.  Therefore,  the  complete  history  of  process  interactions  can  be  analyzed  by 
examining  the  histories  of  message  traffic  among  processes. 
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3.10  NuprI 

5.10.1  Overview 

The  Nuprl  system  is  the  result  of  several  experiments  using  Proof  Refinement  Logics  at  Cornell 
University.  It  has  been  used  primarily  as  a  tool  to  study  constructive  type  theory  as  applied  to 
mathematics. 

Nuprl  represents  a  different  approach  towards  formally  veriiiedprograms.  It  is  based  on  con¬ 
structive  logic:  to  prove  that  there  exists  an  entity  with  a  certain  property  one  shows  how  such  an 
entity  may  be  obtained.  Propositions  in  this  lo^c  therefore  have  a  computational  content.  More 
details  of  the  constructive  approach  can  be  obtained  in  [Con85]. 

The  system  is  quite  powerful  as  a  result  of  the  nse  of  the  ML  metalanguage.  This  language, 
which  also  serves  as  the  basis  of  other  systems  such  as  HOL  and  LCF-LSM,  is  very  adequate  for 
expressing  proof  generating  programs.  What  differentiates  Nuprl  from  these  other  systems  is  its 
reliance  on  constructive  type  theory. 

5.10.2  Execution  and  Rapid  Prototype  Support 

The  Nuprl  language  allows  for  an  explicit  reference  to  the  computational  content  of  propositions 
in  its  logic.  This  is  given  by  using  the  term-of  operator.  When  applied  to  a  proof  outline  (or 
a  complete  proof)  it  extracts  the  information  needed  for  execution.  In  Nuprl  the  theorem  prover 
behaves  more  like  a  compiler  than  an  evaluator. 

The  computational  content  arises  from  the  extraction  form  associated  with  every  Nuprl  proof 
rule.  Nuprl  terms  obtained  from  extraction  terms  have  constructs  corresponding  to  those  in  stan¬ 
dard  programming  languages. 

The  process  of  evaluating  a  term  consists  in  taking  the  noncanonicaiform  of  an  extracted  term 
and  reducing  it  to  obtain  a  term  closer  to  a  canonical  form. 

S.IO.S  Abstraction  Mechanisms 

There  is  no  explicit  notion  of  abstraction,  as  the  language  is  a  very  simple  functional  notation.  On 
the  other  band  the  computational  content  of  the  proof  -  the  extract  form  -  is  hidden  from  the  user, 
and  manipulated  mechanically  by  the  system.  This  is  not  rigid  however  -  termss  can  be  explicitle 
manipulated  by  the  system. 

S.10.4  Forms  of  Logic  Supported 

The  type  theory  forming  the  basis  of  Nuprl  is  derived  ffom  typed  lambda  calculus,  a  functional 
notation  supporting  higher  order  logic.  The  lambda  calculus  has  been  extended  to  model  a  richer 
type  structure,  including  dependent  types,  propositions  as  types,  and  layering  of  type  universes 
into  large  types. 

The  semantics  of  Nuprl  is  therefore  linked  to  the  concept  of  types  -  equality  of  types,  mem¬ 
bership  in  a  type,  equality  within  a  type,  and  so  on. 

The  power  of  type  theory  allows  us  to  use  it  to  model  several  other  logics.  The  type  constructors 
of  Nuprl  -  disjoint  union,  cartesian  products,  etc  -  can  be  used  to  express  logical  connectives  in 
classic  logic. 

Nuprl  also  has  built  in  definitions  for  integers  and  lists,  along  with  appropriate  induction  forms; 
this  allows  for  easy  modeling  of  number  theory.  A  set  constructor  is  also  implemented  primitively 
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in  the  logic. 


5.10.5  Verification  and  Theorem  Proving  Supported 

The  methodology  used  for  proofs  in  Nuprl  is  top-down,  based  on  the  concepts  of  refinements 
and  tactics.  These  tactics  are  metalanguage  procedures  which  manipulate  terms  by  embodying 
the  rules  of  inference  available.  Tactics  can  be  used  to  manipulate  proofs,  obtain  subterms,  and 
perform  many  other  operations  on  the  object  language  entities. 

Refinement  is  provided  by  applying  a  rule  to  a  goal  and  obtaining  tubgoals,  which  will  be  the 
next  objects  to  which  rules  must  be  applied.  Rules  may  also  completdy  prove  a  goal.  The  proof  is 
therefore  tree-structured. 

The  form  of  theorem  proving  relates  to  the  concept  of  propositions  as  types  -  the  proof  must 
show  that  the  type  specified  by  the  proposition  is  inhabited.  This  is  done  by  using  types  which 
are  known  to  be  inhabited  -  say  the  integer  tjrpe  -  and  using  type  constructors  to  obtain  the  type 
characterizing  the  proposition.  The  user  must  show  that  the  type  is  inhabited  by  some  element; 
this  element  turns  out  to  be  the  proof  itself. 

The  rules  which  manipulate  goals  are  specified  in  three  ways:  parsep  Oin 

•  tntro  rules:  break  down  the  conclusion  of  goals  into  subgoals; 

•  elim  rules:  apply  a  specified  hypothesis; 

•  reduce  rules:  rules  fo:  computation. 

5.10.6  Specification  Checking — Completeness,  Consistency,  and  Soundness 

Problem  statements  are  written  in  the  typed  lambda  calculus  notation.  Specifications  constitute 
the  top  node  of  the  proof  trees.  All  the  nodes  of  this  tree  have  a  seguent  >  a  goal  and  an  associated 
list  of  hypotheses. 

The  soundness  of  definitions  in  Nuprl  follows  from  the  soundness  of  type  theory.  Types  defined 
by  users  must  be  proved  to  be  well  formed. 

5.10.7  Formal  System  Basis — Completeness,  Consistency,  and  Soundness 

The  logic  of  Nuprl  is  based  on  Intuitionistic  logic  -  classic  logic  without  the  law  of  the  excluded 
middle.  The  absence  of  this  law  as  a  proof  method  implies  that  proofs  based  on  contradiction  are 
not  allowed.  Any  function  definable  in  this  Intuitionistic  logic  has  been  proved  by  Kleene  to  be 
Turing  computable. 

Type  theory  as  such  is  a  result  of  a  large  amount  of  mathematical  and  philosophical  research 
aimed  at  a  logic  which  is  powerful  enough  to  represent  large  amounts  of  fonnal  knowledge  and  yet 
providddess  soundness  and  consistency. 

5.10.8  Examples 

The  first  example  we  show  here  is  from  (C*86}  and  involves  a  proof  of  the  law  of  the  excluded 
middle,  that  is  that  for  a  proposition  P  either  P  or  P  is  true,  but  not  both.  This  exlusive-or  is 
represented  by  the  Nuprl  operator  vel 

Figure  Sshows  the  beginning  of  this  proof,  the  subgoals  have  been  formed  by  the  system.  Goals 
which  are  labeled  by  a  •  indicate  incomplete  proofs,  while  those  marked  with  a  «  indicate  goals 
which  have  been  proved.  Sequents  are  represented  as  hypotheses  separated  from  goals  by 
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9  top 

»  »11  P:U1.  P  *•!  *P 

BY  intro  at  U2 

19  1.  P:(U1) 

»  (P  Tal  'P) 

2*  »  (Ul)  in  U2 

Figure  5:  Proof  of  excluded  middle 

9  top  1 
1.  P:(U1) 

»  (P  eel  "P) 

BY  intro  at  01 

19  1.  P:(U1) 

2.  'Pf'P 
»  void 

2*  1.  P:(U1) 

»  -pf'P  in  01 

Figure  6:  Proof  of  the  law  of  excluded  middle,  cont. 

The  fix«t  tactic  applied  consists  in  generalizing  the  type  of  P  to  indicate  an  arbitrary  propo¬ 
sitional  variable.  Application  of  the  intro  rule  results  in  a  second  subgoal  of  type  membership, 
which  is  usually  solved  automaticaUy. 

The  empty  type  is  indicated  by  void;  the  proposition  shown  in  Figure  6therefore  says  that 
denotes  an  empty  type. 

The  rest  of  the  proof  is  straightforward  manipulation,  and  is  shown  in  Figure  7. 

The  previous  proof  did  not  provide  any  computational  content,  it  is  simply  a  proof  about  the 
logic.  In  Figure  8we  show  a  proposition  and  the  evaluation  of  its  extract  term.  The  body  of  the 
proof  is  not  being  shown  for  conciseness.  The  proposition  indicates  that  for  any  two  integers,  either 
they  are  equal  or  there  exists  another  integer  which  added  to  one  of  them  results  in  the  other.  The 
computational  content  of  this  is  a  procedure  which  gives  the  difference  beetwen  two  integers. 

The  evaluator  has  an  ML  interface,  thus  the  notation  looks  slightly  different  from  the  proof 
environment.  Functions  are  indicated  by  a  lambda  calculus  notation  using  \  as  an  approximation 
to  A.  The  word  axiom  refers  to  the  leaves  of  the  proof  with  no  computational  content.  We  will 
not  explain  details  of  the  functional  notation  used.  The  expression  tha  refeers  to  the  theorem  just 
proved. 

The  Nuprl  system  uses  windowing  environments,  and  these  transcripts  are  just  an  approxima¬ 
tion  of  the  actual  interaction. 

S.10.9  Critical  Remarks 

This  system  has  evolved  mostly  as  a  tool  for  reasoning  about  mathematics  andd  incorporating 
several  interesting  reults  in  typee  theory.  As  such  there  hasn’t  been  much  concern  with  producing 
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«  top  1  1 

1.  P:(01) 

2.  *Pf'P 
»  void 

BY  olia  2 

1#  1.  P:(01) 

2.  -PB—P 

3.  'P 

4.  —P 
»  void 

BY  olia  4 

1*  1.  P:(U1) 

2.  "Pt-'P 

3.  -P 

4.  — P 
»  -P 

2*  1.  P:(U1) 

2.  ’PB-'P 

3.  -P 

4.  *‘P 
6.  void 
»  void 

Figure  7:  Proof  of  the  l&w  of  excluded  middle,  cont. 
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Figure  8:  Proposition  and  its  extract  term 
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production  quality  software.  The  main  aim  instead  has  been  to  explore  methodologies. 

On  the  other  hand  it  has  been  applied  to  verification  of  hardware,  of  transformations,  and  pro¬ 
grams,  without  using  the  elegant  concepts  described  above,  for  example  considering  propositions  as 
types.  Without  these  the  interaction  with  Nuprl  becomes  very  similar  to  that  with  proof  checkeers 
such  as  HOL. 

The  use  of  Nuprl  for  verification  of  real  programs  of  significant  complexity  is  yet  to  be  achieved. 
Instead  it  provides  a  different  paradigm  for  reasoning  about  problems  and  structuring  information 
logically. 
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3.11  VDM 

The  Vienna  Development  Method  (VDM)  is  a  weQ-ettablished  representative  of  the  model-based 
approach  to  specification  [Bjo78]  [Jon78]  (6jo80]  [Jon86]  [Jon80]  [CHJ86]  [Jon83].  Its  evolution 
began  in  1966  with  the  Universal  Language  Description  language,  an  attempt  to  formally  define 
PL/I.  In  1969,  the  Vienna  Development  Language  was  developed  as  a  method  for  formally  defining 
abstract  interpreters.  Then  in  1974,  VDM  was  developed  as  a  denotational  approach  to  specifying 
software  systems;  its  metalanguage,  Meta-IV,  was  also  defined  at  this  time. 

With  a  model-based  approach,  a  specification  is  a  model  constructed  from  weU-defined  prim¬ 
itives  that  maintain  a  state.  A  specification’s  state  is  a  composite  data  object  that  is  only  visible 
to  the  specification’s  operations.  An  operation  can  be  invoked  by  a  user  to  effect  changes  to  the 
state. 

These  primitives  can  be  abstract  or  concrete.  Using  concrete  primitives  results  in  a  rather 
operational  specification  (i.e.,  a  specification  can  look  like  code). 

VDM’s  metalanguage,  META-IV,  is  considered  to  be  "enriched”  logic.  Theorem  proving  is 
done  after  an  algorithmic  transformation  to  raw  logic. 

VDM’s  built-in  data  types  and  operations  make  it  very  «itni1ar  to  the  denotational  approach 
to  specifying  programming-language  semantics.  Data  objects  are  defined  by  abstract  mathematical 
types.  Operations  are  de^ed  either  implicitly  or  explicitly.  A  specification  is  refined  by  making 
data-object  representations  more  concrete.  This  is  called  data  reification.  Operations  are  then 
redefined  for  the  reified  data  structures.  The  relationship  between  a  specification  and  an  imple¬ 
mentation  is  recorded  in  a  retrieve  function  and  invariants  are  proven  by  structural  induction. 

VDM  provides  a  rich  variety  of  built-in  data  types  and  associated  operators.  Scalars  are 
the  simple  boolean,  numeric,  and  enumerated  types  found  in  most  programming  languages.  Sets, 
tuples,  maps,  and  trees  are  the  structured  types.  A  tuple  is  a  cartesian  product;  it  can  model  a 
pair,  a  list,  or  a  record.  A  map  is  a  finite-domain  function;  it  can  model  an  array  or  a  hash  table. 

A  specification  can  employ  implicit  or  explicit  operations.  Implicitly  defined  operations  use 
applicative  constructs.  For  example,  recursive  functions  can  define  predicates  that  appear  as  precon¬ 
ditions  and  postconditions.  Explicitly  defined  operations  use  imperative  constructs.  VDM’s  explicit 
operations  include:  assignment  with  selection  with  if -then-alse,  iteration  with  vhile-do  and 
f  or-all-do,  nondeterminism  with  a  "parallel”  statement,  and  sequendng  with  ; . 
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4  Design  of  a  Prototype  Short-Term  Workbench 
4.1  Overview 

Based  on  the  knowledge  gained  from  our  survey,  we  have  begun  the  design  and  implementation 
of  a  prototype  short-term  workbench.  The  goal  for  the  workbench  is  to  provide  computer-based 
support  for; 

•  The  high-level  specification  of  a  concurrent/distributed  software  system 

•  The  verification  of  the  high-level  specification,  with  emphasis  on  the  verification  of  security 
properties 

•  The  implementation-level  specification  of  a  concurrent /distributed  software  system 

•  Verification  that  the  implementation-level  specification  is  correct  with  respect  to  the  high-level 
specification 

•  Implementation  of  the  specified  software  in  an  efficient,  concurrent /distributed  programming 
language 

•  Verification  that  the  implementation  is  correct  with  respect  to  the  implementation-level  spec¬ 
ification  (and  thereby  correct  with  respect  to  the  high-level  specification) 

For  the  overall  architecture  we  have  chosen  a  two-tiered  approach  to  specification,  as  developed 
originally  in  the  Larch  system  [Win87],  [Hor85],  [GHW85].  Since  Larch  was  developed  solely  for 
specification  of  sequential  programs,  a  major  component  of  our  research  is  to  add  capabilities  to 
specify  concurrent  and  distributed  programs. 

Figure  1  is  a  high  level  diagram  of  the  major  conceptual  levels  of  the  workbench.  The  top  two 
levels  are  the  separate  tiers  of  the  specification,  and  the  bottom  level  is  the  concrete,  executable 
program.  The  algebraic  tier  of  the  specification  expresses  the  highest  levels  of  software  abstraction. 
In  general,  the  algebraic  tier  presents  specifications  in  an  object-oriented  style,  in  which  the  basic 
unit  of  specification  is  an  object  description.  Accompanying  each  object  specification  is  a  set  of 
basic  operations  on  that  object,  plus  a  set  of  equations  that  formally  specify  how  the  operations 
behave. 

The  axiomatic  tier  of  the  two-tier  specification  provides  the  interface  between  the  high-level 
algebraic  abstractions  and  the  concrete  programming  language.  In  our  Larch-inspired  approach, 
the  axiomatic  tier  is  represented  concretely  by  an  axiomatic  semantic  description  of  the  SR  pro¬ 
gramming  language. 

The  annotations  shown  in  italics  in  Figure  1  describe  the  framework  for  formal  verification 
in  a  two-tiered  system.  Specifically,  the  objects  and  operations  are  verified  to  be  complete  and 
consistent  at  the  algebraic  tier.  Such  verification  is  based  on  known  techniques  from  the  study 
of  algebraic  semantics.  Once  the  operations  have  been  validated  at  the  abstract  algebraic  level, 
they  can  be  used  to  specify  pre-  and  post-conditions  to  be  satisfied  by  the  (SR)  program  at  the 
axiomatic  level. 

A  significant  advantage  of  the  two- tier  approach  is  that  critical  properties  of  the  software  system 
can  be  stated  at  the  appropriate  level  of  abstraction.  The  algebraic  tier  of  a  specification  is  the  level 
at  which  high-level  properties  of  a  software  system  and  stated  and  verified.  For  example,  abstract 
properties  of  security  can  be  stated  and  verified  at  the  algebraic  level.  Once  these  properties  are 
established  and  verified  at  the  abstract  algebraic  level,  more  concrete  properties  of  the  program 
can  be  stated  and  verified  at  the  ariomatic  tier.  For  example,  one  would  state  and  verify  that  the 
program  correctly  implements  the  security  properties  that  were  verified  abstractly  at  the  algebraic 
level. 
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Figure  1:  Three  Conceptual  Levels  of  the  Spedficatioa  end  Verification  PVumework 
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Figure  2:  Tool  Components  of  the  Prototype  System 

Based  on  our  two-tiered  framework.  Figure  2  shows  the  tool  components  which  comprise  our 
initial  design  of  a  prototype  specification  and  verification  system.  The  tool  to  support  the  algebraic 
tier  will  be  a  system  such  as  0BJ3,  augmented  with  features  to  support  the  specification  of  concur¬ 
rency.  The  SR-based  verification  tool  will  assist  in  the  management  of  the  axiomatic  specification  of 
the  SR  program.  **Annotated-SR"  refers  to  a  version  of  the  language  with  syntactic  enhancements 
to  support  the  use  of  verification  annotations  attached  directly  to  the  program.  Such  annotations 
include  pre-  and  post-conditions,  module  invariants,  and  other  axiom-based  assertions. 

SUgh-level  control  of  the  specification  and  verification  are  provided  by  the  editor-based  proof 
manager,  and  a  set  of  general  software  development  tools  common  to  an  advanced,  workstation- 
based  software  environment.  It  should  be  noted  that  while  the  T^eemacs  proof  manager  is  shown 
as  a  physically  separate  component  in  Figure  2,  it  is  in  fact  a  well-integrated  component  of  the 
general  environment  tools.  In  particular,  as  the  name  "Tyeemacs”  suggests,  the  proof  manager  is 
based  on  the  same  general-purpose  Emacs  editor  that  is  used  for  all  other  forms  of  specification 
and  program  editing.  This  form  of  uniform,  editor-based  interface  is  common  in  most  advanced 
software  development  environments  today. 
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The  roles  of  the  key  componeots  shows  in  Figure  2  axe  introduced  briefly  just  below.  Then 
in  sections  4.2  through  4.5  we  present  extended  descriptions  of  our  research  on  key  components  of 
the  workbench. 

4.2  The  Role  of  the  FASE,  HOL,  and  OBJ3  High-Level  Specification  Languages 

In  our  two>tiered  approach,  the  top  tier  consists  of  an  object-oriented,  high-level  specification 
language.  There  are  several  such  languages  available  for  the  specification  of  sequential  programs. 
At  present  we  are  pursuing  a  multi-language  approach  for  the  high-level  specification  tier.  The 
languages  we  are  using  are  FASE,  HOL,  and  OBJ. 

There  is  much  recent  support  in  the  software  engineering  literature  for  mixed-language  software 
development  environments.  The  advantages  of  a  mixed-language  system  stem  from  difficulty  in 
finding  a  a  single,  fully  general-purpose  language  that  satisfies  aU  users  needs.  Bather,  it  is  'more 
likely  that  a  family  of  more  specialised  languages  can  be  put  together  in  common  environment, 
allowing  users  to  choose  the  language  most  suited  to  a  particular  problem  and/or  the  language 
with  which  a  user  has  the  most  experience. 

Most  of  the  work  reported  in  the  literature  discusses  mixed-language  environments  at  the  level 
of  the  concrete  programming  language.  Here  we  are  extending  the  mixed-language  concept  to 
higher-level  specification  languages.  Hence,  in  our  workbench  we  will  allow  user  the  freedom  to 
choose  from  a  set  of  specification  languages,  having  the  environment  supply  a  well-defined  interface 
between  components  of  a  specification  written  in  different  languages.  One  of  the  areas  of  research 
to  be  performed  is  how  and  at  what  level  to  define  the  intrat-language  interface.  We  will  conduct 
this  research  based  on  our  experience  with  mixed-language  programming  environments. 

It  is  possible  as  the  development  of  the  workbench  progresses,  we  vriU  find  that  the  mixed- 
language  approach  is  not  satisfactory,  either  because  of  the  excess  overhead  to  requires  to  manage 
mixed-languages  specifications  or  because  technical  difficulties  arise  in  developing  the  intra-language 
interface.  At  present,  however,  the  mixed-language  approach  is  advantageous  and  we  plan  to  pursue 
as  long  as  possible. 

One  of  the  best  known  is  the  0BJ3  language,  developed  at  SRI  by  Goguen  and  his  associates. 
We  have  been  gaining  experience  with  0BJ3,  and  find  it  a  useful  vehicle  for  high-level  specification. 
We  are  not  yet  as  firmly  committed  to  0BJ3  as  we  are  to  SR,  since  there  are  several  other  algebraic 
languages  that  have  been  implemented  that  we  plan  to  evaluate  thoroughly  before  making  our  final 
decision.  We  can  say  that  our  initial  experience  with  0BJ3  has  been  positive. 

Another  main  component  of  our  research  is  the  extension  of  a  high-l^el  specification  language 
to  support  the  specification  of  concurrent  programs.  Section  4.2  below  describes  the  details  of  our 
ongoing  work  with  0BJ3,  including  extensions  to  handle  specification  of  concurrency  in  an  algebraic 
framework.  While  the  current  work  is  in  the  concrete  framework  of  0BJ3,  it  is  conceptually 
applicable  to  other  algebraic  languages,  including  potentially  FASE  and  HOL. 

4.3  The  Role  of  the  SR  Programming  Language 

SR  (Synchronising  Resources)  is  a  language  for  writing  concurrent  programs.  It  provides  more 
ficxibility  in  the  way  processes  synchronise  and  communicate  than  do  other  languages,  including 
Ada.  For  example,  SR  provides  both  synchronous  and  asynchronous  operation  invocation  whereas 
Ada  provides  only  synchronous;  having  the  asynchronous  form  simplifies  many  programs. 

There  are  two  primary  rationale  for  choosing  SR  as  our  base  programming  language.  The 
first  and  most  important  rationale  is  purely  technical  -  we  feel  that  SR  provides  one  of  the  most 
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conceptually  sound  and  complete  vehicles  in  which  to  express  concurrent  and  distributed  programs 
While  there  are  other  languages  that  express  certain  features  of  concurrency  well,  SR  is  reasonably 
unique  in  its  support  of  a  full  range  of  concurrency  features  in  a  conceptually  uniform  manner. 

The  second  rationale  for  the  choice  of  SR  is  pragmatic.  Namely,  several  of  our  team  members 
have  considerable  experience  with  the  language  and  its  implementation.  Since  UC  Davis  is  one  of 
the  primary  development  sites  for  the  language,  we  are  in  a  position  to  design  language  extensions 
that  may  be  necessary  to  fit  our  evolving  specification  and  verification  methodology.  No  other 
language  affords  us  as  clear  an  opportunity  for  evolving  the  language  to  fit  our  methodological 
needs. 


4.4  The  Role  of  the  Annotated-SR  Verification  Tool 

This  is  the  component  of  our  prototype  methodriogy  that  is  the  least  wdl-devdoped  at  this  point. 
Tool  support  for  axiomatic  verification  has  been  developed  almost  exclusively  for  sequential  as 
opposed  to  concurrent  programming  languages.  By  tool  support  in  this  context,  we  mean  those 
tools  that  produce  theorems  (actually  conjectures,  pending  their  proof)  corresponding  to  properties 
the  user  proposes  to  verify  about  the  program.  These  tools  are  conventionally  called  verification 
condition  generators.  Special  purpose  verification  condition  generators  have  been  developed  for 
particular  properties  of  sequential  programs,  such  as  information  flow  related  to  multilevel  security. 
For  the  verification  of  concurrent  programs,  the  verification  condition  generator  must  consider  all 
possible  interleavings  of  operations.  This  can  lead  to  formidable  theorems,  the  management  and 
simplification  of  which  will  be  addressed  in  our  research. 

The  initial  necessary  step  to  an  axiomatic  verification  support  tool  is  the  development  of  the 
formal  axiomatic  semantics  of  our  base  language  -  namely  SR.  This  is  a  substantial  research  effort  in 
its  own  right,  details  of  which  are  covered  in  section  4.5  below.  Once  our  work  on  the  semantics  has 
developed,  we  will  begin  to  consider  the  problem  of  verification  condition  generation  for  concurrent 
programs.  This  research  will  involve  a  blending  of  the  work  of  several  current  researchers  who  have 
addressed  different  aspects  of  the  axiomatic  verification  of  concurrency. 

4.5  The  Role  of  TED/Tkeemacs  Theorem  Proving  Support  Systems 

The  role  of  the  theorem  prover  is  to  verify  the  verification  conditions.  Numerous  mechanical 
theorem  provers  are  now  available  and  we  have  been  gaining  practical  experience  with  several.  Also 
available  is  the  TED/IVeemacs  *  system  that  supports  the  management  of  the  theorem  proving 
process.  TED/TVeemacs  is  a  tree-editor-based  system  that  can  provide  a  uniform  interface  to  a 
variety  of  theorem  provers  and  allows  users  to  conveniently  structure  and  carry  out  proofs. 

In  the  context  of  program  verification,  it  is  convenient  to  view  four  classes  of  theorem  provers: 

•  first-order  logic-based,  using  resolution  as  the  primary  rule  of  inference  (there  are  many  of 
these  av^able,  the  best  supported  being  those  developed  at  Argonne  and  the  University  of 
Illinois) 

•  first-order  logic-based,  using  natural  deduction  (e.g.,  the  Bledsoe  theorem  prover  as  used  in 
the  Afl&rm  and  Gypsy  verification  systems) 

•  first-order  based,  with  nser-supplied  instantiations  (e.g..  Muse  and  the  theorem  prover  of  the 
Enhanced  EDM  verification  system) 

‘TED  and  TVeemacs  axe  baaed  oa  foadameBtally  the  same  piiadplea;  TVeemace  ia  the  aaeeeaaor  to  TED,  coataiaiag 
seme  updated  capabilities  and  better  iategxatioa  with  the  caxreat  release  of  the  Emacs  editoi. 
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•  recursive  function-based  (e.g.,  Boyer-Moore  and  LCF  theorem  provers). 

As  our  methodology  for  concurrent  veriiication  evolves,  we  will  consider  how  each  of  classes  can 
and  should  be  used  in  the  veriiication  task. 

As  noted  above,  we  have  not  yet  determined  what  role  temporal  logic  will  play  in  the  method¬ 
ology  we  develop.  It  seems  reasonably  clear  at  this  point  that  one  or  two  fundamental  properties 
of  temporal  logic  are  necessary  to  reason  completely  about  concurrent  programs  at  the  axiomatic 
specification  level.  We  are  not  sure  at  all  what  role,  if  any,  temporal  logic  may  play  at  the  algebraic 
specification  level.  If  some  form  of  temporal  logic  or  the  equivalent  is  necessary  at  some  level  of 
specification,  this  will  have  a  definite  impact  on  the  theorem  proving  support  required. 
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5  Algebraic  Specification  and  Verification  of  Concurrency  in  OBJ 

At  described  in  the  introduction,  we  have  begun  initial  experimentation  with  algebraic  specifications 
for  concurrency  within  the  framework  of  the  0BJ3  system.  Specifications  at  the  algebraic  level  have 
several  appealing  properties,  including; 

1.  The  algebraic  semantics  are  founded  on  fully  formal  mathematical  principles 

2.  Algebraic  specifications  are  executable  via  rewrite  rule  interpretation 

3.  Support  for  formal  verification  is  provided,  also  in  the  form  of  rewrite  rule  application 

4.  A  layered  approach  to  specification  is  possible  within  the  general  object-oriented  firamework 
of  algebraic  specification;  this  layering  fosters  the  definition  of  understandable  specifications, 
and  helps  subdivide  the  refinement  and  verification  of  specifications  into  manageable,  logical 
steps 

5.1  Overview  of  the  Approach 

A  major  goal  of  research  in  the  verification  methodology  is  the  development  of  mathematical 
techniques  for  demonstrating  that  a  program  is  correct.  These  techniques  are  even  more  valuable 
when  they  can  be  applied  to  the  verification  of  a  concurrent  program.  In  this  section,  we  investigate 
how  an  equational  language  can  be  used  to  specify  concurrency  and  how  its  interpreter  can  be  used 
as  a  theorem  prover  to  demonstrate  correctness. 

At  first  glance,  automatic  program  verification  appears  to  offer  a  tremendous  benefit:  bug-free 
software.  Upon  closer  examination,  however,  verification  techniques  can  only  detect  a  small  class 
of  the  many  ways  in  which  a  program  may  fail  to  execute  as  desired  [Gog88].  Nevertheless,  this 
class  is  important.  In  particular,  it  usually  contains  the  class  of  failures  that  are  detectable  by  the 
programmer’s  test  suite. ^  Testing  a  sequential  program  is  not  always  easy;  thoroughly  testing  a 
concurrent  program  is  often  very  difficult.  Therefore,  the  study  of  automatic  verification  techniques 
for  concurrent  programs  is  a  worthwhile  pursuit. 

There  are  several  approaches  to  specification;  a  popular  dichotomy  is  the  axiomatic  approach 
and  the  algebraic  approach  [GM86a].  Among  the  algebraic  methods,  those  with  first-order  equations 
as  their  assertion  language  have  the  simplest  semantics.  Such  specifications  are  easy  to  write 
and  understand;  they  are  also  relatively  easy  to  interpret.  Thus  an  equational  specification  is 
executable.  In  practice,  this  is  very  important.  Notice  that  an  executable  specification  is  essentially 
a  program.  Equational  languages  are  often  advertised,  therefore,  as  '*very  high-level”  or  "wide- 
spectrum”  languages. 

OBJ3  is  just  such  a  language.  Its  advantages  over  other  equational  languages  are:  mod¬ 
ule  parameterixation,  operation  overloading,  subsorting,  and  availability.  These  are  all  important 
software-engineering  features.  The  language  is  described  in  Section  5.2. 

The  main  body  of  this  section  contains  the  results  of  experiments  that  use  OBJ3  as  a  veri¬ 
fication  tool.  Section  5.4  describes  a  technique  for  modeling  concurrency  in  OBJ3,  Sections  5.3 
and  5.5  employ  the  technique  to  develop  a  specification  for  the  classic  Readers /Writers  problem. 
Section  5.6  verifies  an  important  property  of  this  specification. 

^Experience  shows  thst  s  nser  is  mote  prone  to  progrnm  nbnse  then  the  profTsinmei. 
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Section  5.7  proposes  extensions  to  OBJ3  that  provide  a  message-passing  mechanism  reminis¬ 
cent  of  that  found  in  CSP.  A  message-passing  version  of  the  Readers/Writers  problem  is  also 
presented. 

A  concurrent  program  is  composed  of  atomic  actions,  which  can  each  be  proven  correct  by 
existing  sequential  methods.  Section  5.8  revisits  an  early  paper  on  sequential-program  verification 
and  demonstrates  that  OBJ3  can  automate  many  of  the  steps.  Here,  the  verification  is  somewhat 
different:  an  implementation  is  proven  correct  with  respect  to  a  specification. 

Section  5.9  recognizes  that  the  results  presented  here  are  preliminary  and,  therefore,  identifies 
future  research  directions.  These  include  implementing  the  extensions  proposed  in  Section  5.7  and 
attempting  larger  and  more  complex  examples. 

5.2  The  OBJ  Language 

This  section  provides  a  very  brief  overview  of  OB  J3.  If  a  seemingly  esoteric  feature  is  described 
here,  it  is  probably  used  in  a  later  section.  For  more  det^,  consult  the  reference  manual  [GW88]. 
OBJ3  is  an  equational  programming  language  designed  for  the  specification  and  implementation  of 
abstract  data  types.  Its  denotational  semantics  are  based  on  order  sorted  algebra,  its  operational 
semantics  are  based  on  order  sorted  term  rewriting.  An  interpreter,  written  in  Lisp,  is  available 
from  SRI  International. 

OBJ3’s  encapsulation  unit  is  the  object.  An  object  can  contain:  importing  instantiations  of 
other  objects;  sort,^  subsort,  operation,  and  variable  declarations;  and  equations.  An  object  can 
be  parameterized. 

An  operation  declaration  specifies  the  name,  arity,  and  coarity  of  an  operation.  For  a  mixfix 
operation,  the  argument  positiozu  are  declared  by  embedding  underbars  in  the  operation  name  (e.g  , 
Various  operation  attributes  can  also  be  defined.  These  include  associativity,  commutativity, 
a  precedence,  and  an  evaluation  strategy.  An  evaluation  strategy  specifies  the  order  in  which 
arguments  are  evaluated;  it  allows  operations  to  be  "eager”  (the  default)  or  "lazy”.  For  example, 
the  evaluation  strategy  for  if.then_el8a_f i  is  strategy  (1  0).  The  numbers  in  parentheses 
correspond  to  argument  positions.  Thus,  the  first  argument  is  reduced  first;  the  0  then  causes 
equations  for  if_then.elee.fi  to  be  applied.  Since  there  is  no  2  or  3,  the  then  and  else  subtenns 
are  not  reduced  at  this  time. 

An  equation  specifies  how  a  term  can  be  reduced.  That  is,  it  specifies  a  relationship  between 
two  or  more  operations.  If,  after  variable  binding,  the  LHS  of  an  equation  is  equal  to  a  subterm,  that 
subterm  can  be  reifiaced  by  the  equation’s  RHS  using  the  variable  bindings.  Conditional  equations 
are  also  supported.  A  conditional  equation  is  applicable  only  when  its  associated  boolean  condition 
is  true. 

Figure  1  contains  an  object  that  defines  a  stack  of  integers;  it  also  shows  some  sample  reduc¬ 
tions.  The  keyword  protecting  is  a  form  of  import.  ZIT  is  a  built-in  object  that  provides  sort  Int 
and  the  expected  operations  on  integers.  OBJ3  contains  various  built-in  objects  defining  booleans, 
naturals,  integers,  reals,  and  alphanumeric  identifiers.  Pol]rmorphic  equality  (.■■_),  inequality 
(.■/■_),  and  conditional  (if  _than.else_f  i)  operations  are  also  provided.  The  op  keyword  intro¬ 
duces  an  operation  declaration.  For.  example,  new  is  a  constant  operation  that  represents  the  empty 
stack  and  top  is  a  function  that  takes  a  single  argument  of  sort  Stack  and  returns  an  integer.  Vari¬ 
ables  are  declared  with  the  var  keyword.  The  eq  keyword  introduces  an  equation;  cq  is  used  for 
a  conditional  equation.  Here,  the  equations  define  stack-operation  semantics,  including  (pathetic) 

*Al(vb(sisU  prefer  ‘•ort*  over  "type”. 
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•bjact  tTACI>OF-IIT  !■  sort  St*ck  . 
prataetlBg  IIT  . 

•p  >«•  I  •>  Stack  . 

•p  paah  :  lat  Stack  ->  Stack  . 

ap  pap  :  Stack  ->  Stack  . 

ap  tap  :  Stack  ->  lat  . 

var  S  :  Stack  . 

var  I  i  lat  . 

aq  pap(aaB)  ■  aaa  . 

aq  pap(pash(I,S>)  ■  S  . 

aq  tap(aaa>  ■  0  . 

aq  tap(pash(I.S))  ■  1  . 

(a):  Object. 


radaea  ia  STACI-OF'-IIT  :  tap(pap(pBsh(l,pash(3,aaB>))) 
rawritas:  2 
rasalt  Salat:  2 


radaea  ia  ST1CS-0F*IIT  i  tap<pap<paah(l.aae))) 
raeritaa:  2 
raaalt  Sara:  0 


radaea  ia  STACI-OF-IIT  :  pap(pash(3.paah(2.pash(i,aae)))) 
raaritaa:  1 

rasalt  Stack:  pash(2,paah(t,aaa)) 


(b):  Reductions. 

Figure  1:  A  Stack  of  Integers. 


abjaet  lUS'llESAtCIT  ia 
sart  lat  . 
sart  lat  . 
sabsart  lat  <  lat  . 

aada 


Figure  2:  An  Example  of  Subsorting. 


error  handling.  Two  sample  reductions  demonstrate  the  operations’  behavior.  Incidentally,  OBJ3 
has  two  kinds  of  comment,  both  extending  to  the  end  of  the  line.  Those  introduced  by  ***>  print 
during  parsing,  those  introduced  by  •••  do  not. 

OBJ3  is  a  strongly  sorted  language;  however,  it  allows  subsorts  to  be  declared  and  permits 
operation  overloading.  Subsorts  are  useful  when  items  of  one  sort  are  also  items  of  another  sort. 
For  example,  Figure  2  might  be  part  of  a  number  hierarchy.  This  allows  an  operation  that  requires 
an  argument  from  the  supersort  (the  integers)  to  be  applied  to  an  argument  from  the  subsort  (the 
naturals).  Subsorts  make  OBJ3  much  more  fiemble  and  they  simplify  the  ipediication  of  error  and 
exception  handling.  Operation  overloading  is  useful  when  a  single  operation  name  is  used  for  more 
than  one  operation.  The  intended  operation  is  determined  by  the  (lowest)  sort  of  each  argument; 
it  can  also  depend  on  the  required  result  sort.  For  example.  Figure  3  contains  an  overloaded  in&c 
addition  operation.  Overloading  allows  an  equation  to  be  applicable  only  when  the  arguments  are 
of  the  appropriate  sort.  Here  (evidently),  the  overhead  of  complex  addition  is  incurred  only  when 
an  argument  is  actually  complex. 

OBJ3  supports  parameterised  programming.  When  a  parameterized  object  is  instantiated, 
an  actual  parameter  (an  object)  is  bound  to  each  formal  parameter.  Each  actual  parameter  must 
satisfy  the  theory  associated  with  its  corresponding  formal  parameter.  A  theory  defines  the  re¬ 
quirements  of  an  actual  parameter.  The  way  in  which  the  actual  parameter  satisfies  the  theory  is 
specified  by  a  view.^  A  view  is  a  mapping  from  sorts  and  operations  in  the  theory  to  sorts  and 

*OBJ3  k  qoitc  clever  is  dednoBg  defenlt  views. 
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•kjact  CmVLtZ'iPOZTIOl  is 
■arts  Csaplaz  tsal  . 
sp  I  Csi^laa  Caaplaz  •>  Caaplaz  . 
sp  I  Caaplaz  laal  •>  Caaplaz  . 

ap  :  Baal  Caaplaz  ->  Caaplaz  . 

ap  .a.  :  Baal  Baal  •>  Baal  . 
ap  eeadd  :  Caaplaz  Caaplaz  ->  Caaplaz  . 
ap  eradd  ;  Caaplaz  Baal  ->  Caaplaz  . 
ap  rradd  t  Baal  Baal  •>  Baal  . 
aar  C  :  Caaplaz  . 
aar  B  >  Baal  . 
aq  C  a  C  ■  eeadd(C,C)  . 
aq  C  a  B  a  eradd(C.B)  . 
aq  B  a  c  a  eradd(C,B)  . 
aq  B  a  K  a  traddCB.B)  . 
aada 


Figure  3:  An  Ezemple  of  Overloading. 

thaary  BUN  is  sart  Klaa  . 
ap  aadaflaad  i  ->  Klaa  . 

aadth 

abjaet  mCK-Or-KUMCE  ti  BLSH]  is  aart  Stack  . 
ap  aaa  >  ->  Stack  . 
ap  pack  :  Klaa  Stack  ->  Stack  . 
ap  pap  I  Stack  ->  Stack  . 
ap  tap  t  Stack  *>  Klaa  , 
aar  S  :  Stack  . 
aar  K  )  Klaa  . 
aq  pap(aaa)  ■  aaa  . 
aq  pap(pBah(C,S))  ■  S  . 
aq  tap<aas)  ■  asdafiaad  . 
aq  tsp<pash<K.S) )  ■  B  . 

aada 


aias  BUDI*T0«1BT  fraa  KLXM  ta  IKT  la 
sart  Klaa  ta  lat  . 
ap  aadaflaad  ta  0  . 


aaka  STBCB>Or-IfT  ia  ariffa-nr-ai aafri aa-an-TSTl  ,•4. 

Figure  4:  Another  Stack  of  Integers. 


operations  in  the  actual  parameter.  Figure  4  defines  a  stack  of  integers  as  before,  but  by  instan¬ 
tiating  a  generic  stack  object  srith  the  IIT  object.  ELEM  is  a  theory  requiring  the  parameter  E*  to 
provide  a  sort  named  Elem  and  a  coxutant  of  sort  Elea  named  undefined.  ELEM-TO-INT  is  a  view 
describing  how  IIT  satisfies  ELEK.  The  sort  mapping  is  the  obvious  one;  xero  is  designated  as  the 
top  of  an  empty  stack,  as  before.  Finally,  the  sake  construct  instantiates  a  stack  of  integers;  it  is 
equivalent  to  the  object  in  Figure  5. 

*PanBatcx  I  is  distiaet  from  vuiabk  K  dcdarad  later  ia  the  object.  Ia  fret,  the  panmetei  is  aot  explicitly 
lefaieaced  ia  the  object.  However,  if  it  was  aicamary  to  iastaatiate,  aaj,  a  list  of  elemeats  withia  the  object,  the 
impoct  woald  be  protaetiac  LZSTCQ,  where  K  is  the  parameter. 

ekjaet  STBCS-eP-XBT  U 

pretaetii^  STBCS>eP>BLn[BLBB-TO>XBT]  . 

aada 


Figure  5:  An  Alternative  Method  of  Instantiation. 
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object  SUNIIC  is  pretocting  IIT  . 
op  f  :  lot  Int  •>  lot  . 
op  g  :  lot  ->  Int  .. 
vor  I  3  :  Int  . 
oq  -  I  «  J  . 

oq  g(I)  ■  1  ♦  1  . 

(n):  Object. 


rsdseo  in  SUHIIC  :  f(g<l).g(2)) 
rooritoo:  6 
roonlt  Islnt:  S 


(b):  Redaction. 


Figure  6:  An  Opportunity  for  Concurrent  Term  Rewriting. 


5.3  The  Readers /Writers  Problem 

A  good  example  of  a  small  concurrent  programming  problem  is  the  Readers/ Writers  problem 
[Fin86}.  Tbe  problem  is  to  provide  an  interface  to  a  shared  database.  A  solution  must  arbitrate 
access  to  this  database  between  competing  processes  in  such  a  way  that  the  integrity  of  the  data 
is  maintained.  There  are  two  kinds  of  processes:  readers  traverse  but  do  not  modify  the  database, 
writers  traverse  and  modify  the  database.  Since  the  internal  structure  of  the  database  is  unspecified, 
data  integrity  is  maintained  by  coarse  access  restriction.  Specifically,  if  nr  and  nu>  are  the  number 
of  reader  and  writer  processes  currently  accessing  the  database  (resp.),  the  invariant  in  Equation  1 
must  always  be  true. 

0  <  nr  A  0  <  nw  <  1  A  (nr  =  0  V  nw  =  0)  (1) 

The  key  point  is  that  a  writer  requires  exclusive  access  to  the  database.  Notice  that  the  scheduling 
method  for  blocked  processes  is  unspecified;  we  use  first.come/first-serve  (FCFS)  scheduling. 

5.4  Star  Operations 

This  section  describes  how  OBJ3  can  be  used  to  specify  the  behavior  of  a  concurrent  system. 
Some  clumsiness  should  be  expected  since  we  are  using  a  language  that  has  no  explicit  concur¬ 
rency  mechanisms  to  explicitly  model  concurrency.  This  is  in  contrast  to  th::  concurrent  term 
rewriting  approach  [GKM87],  where  implicit  opportunities  for  concurrency  are  detected  within  a 
sequential  specification.  These  opportunities  are  easy  to  detect  in  OBJ3  because  it  is  a  functional 
language  (i.e.,  operations  cannot  cause  side-effects).  Such  an  opportunity  is  shown  in  Figure  6. 
In  the  reduction,  the  equation  for  g  can  be  applied  concurrently  to  reduce  the  two  arguments  to 
f ,  but  the  equation  for  f  cannot  be  applied  concurrently  with  the  equation  for  g.  Concurrent 
term  rewriting  is  an  alternative  to  the  Von  Neumann  model  of  computation  because  it  avoids  the 
program-counter  bottleneck.  Incidentally,  the  approach  can  also  be  used  to  increase  the  execution 
speed  of  a  concurrent  specification  developed  using  the  techniques  described  below. 

The  first  obstacle  to  overcome  is  related  to  process  naming.  As  in  other  sequential  languakges, 
all  OB  J3  operations  are  invoked  in  the  context  of  a  single  anonymous  process.  However,  we  want  to 
reduce  terms  representing  operation  invocations  from  multiple  processes.  An  important  observation 
is  that  we  are  not  interested  in  the  result  returned  by  every  invocation;  rather,  we  are  interested 
in  the  result  returned  by  a  particular  invocation,  as  affected  by  the  other  invocations.  Therefore, 
we  need  some  way  to  identify  the  invocation  we  are  interested  in.  This  is  done  by  invoking  a 
star  operation,  one  with  the  same  name  except  for  a  prefixed  asterisk.*  Generally  speaking,  each 

*Thcrc  if  aothias  fpcdal  aboat  the  aaminf  csaecatioa,  obj  e^cme  coold  be  oted,  bat  a  ptefixed  Mteiifk  mokes 
the  eoReepoadcace  ebrioai  oad  it  itoads  oat  aicclr  ia  o  tena.  Aa  for  oa  OBJ3  it  coaccraed,  kowcTci,  o  star  operation 
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•kjaet  SOUraoU  ia  tort  Saaapkera  . 
prataetlBf  IIT  . 
sakaart  lat  <  taaapkora  . 
apa  ap  p  aa  V  t  faaaphara  •>  Saaapkara  . 
apa  daaa  aatalda  :  Saaapkara  ->  Saaaphara  . 
aar  S  i  Saaapkara  . 
aar  I  i  lat  . 

cq  ap(I)  ■  daaad  -  1)  if  1  >  0  . 

aq  av(I)  ■  daaad  *  i)  . 
eq  pd)  a  I  .  1  if  1  >  0  . 
aq  ad)  a  1  a  i  . 
aq  V(ap(S»  a  ap(a(S>>  . 
aq  aaipM))  a  p(a«(S))  . 
aq  a(p(S))  a  p<a<S)>  . 
aq  p(daaa(t))  a  daaa<S)  . 
aq  a(daaa(t))  a  daaa(S)  . 
aq  aatsida(daaad))  a  i  . 
aada 


(a):  Objact. 


radaca  ia  tBUraOU  i  aataida<a(ap(o))) 
raarltaat  10 
rasalt  Zarai  0 


radaca  la  SHUnOU  i  aataida(a(a<p<«p(p(0)>)))) 
raaritaas  33 
raaalt  Zara)  0 


radaca  ia  SBunoiZ  :  aataida(ap(T<«(a<p<0)))))) 
raaritaa:  10 
raaalt  Islat:  1 


radaca  la  SDUPHOBE  :  aatalda<*(«p(p(0)))) 
raaritaa;  it 

raaalt  OaMpfearat  aataida(ap(0>) 


radaca  ia  fBuraotC  >  aataida<aa<p<p<p<0)))>) 
raaritaa)  10 
raaiQt  lalat)  i 


(b):  lUdaetioBa. 


Figure  7:  A  FCFS  Semaphore. 


“exported”  operation*  provided  by  an  object  reqoireo  a  corresponding  star  operation;  iti  definition 
U  often  oimilar  and  oometimeo  identical  to  that  of  ito  nonotarred  namesake. 

Unfortunately,  there  are  complications.  For  example,  when  an  exported  operation  relies  on  an 
auxiliary  operation,  an  auxiliary  star  operation  is  often  necessary  to  ensure  that  intermediate  results 
from  other  invocatioiu  do  not  interfere  with  the  result  we  are  interested  in.  F^hermore,  other 
operations  are  usually  necessary  to  reduce  a  term  containing  the  result  of  an  invocation  of  a  star 
operation  to  that  result.  That  is,  the  intermediate  results  of  other  invocations  must  be  eliminated. 
Specifically,  the  result  must  be  moved  toward  the  outside  of  a  term  where,  it  can  participate  in  the 
final  reduction  step. 

Figure  7  contains  an  object  that  uses  star  operations  to  model  the  behavior  of  a  FCFS 
semaphore;  it  also  shows  some  sample  reductions.  SENAPBORE  provides  the  nsual  P  and  V  opera¬ 
tions;  but  because  an  OBJ3  operation  must  always  return  something,  they  return  the  semaphore’s 

value. 

m  ao  diMmmt  from  uy  otbex. 

'Uafortudtcly,  OBJ3  ptoridc*  ae  way  ef  deduiag  tbai  aa  opetaiioa  ia  iaaFfaaaiblc  to  other  objecta.  Thu, 
all  opccatieas  at*  exported.  Oaly  aome  operatioaa,  boarem.  are  iateaded  tor  oataide  aae,  otbexa  are  a)udbary  ia 
aataxe  aad  aboald  aot  be  iavobed  from  oataide  tbe  object.  Note  that  aa  earlier  eeraioa  of  OBJ3  did  aapport  bidden 
operatioaa  [GMIT]. 
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tkaary  EET  ia 
aert  lay  . 
aadth 

tkaary  ITSK  ia 
aort  Itaa  . 

ap  aatfannd  :  ->  Itaa  . 
aadtk 


Figure  8:  The  Requirements  for  D&tabase  Parameters. 


Remember,  this  is  only  a  model;  as  such  it  requires  an  interpretation.  The  remainder  of  this 
section  informally  discusses  this  interpretation. 

For  a  sequential  specification,  nested  operations  in  a  term  model  the  history  of  invocations 
made  by  a  single  process;  that  is,  they  model  the  time-ordering  of  invocations.  With  multiple 
processes,  however,  a  natural  extension  is  to  interpret  nested  operations  in  a  term  as  the  history 
of  concurrent  invocations,  >dxactly  one  of  which  is  a  star  operation.  Thus  in  the  first  reduction 
in  Figure  7,  the  *p  operation  models  a  P  operation  that  blocks  on  a  zero  semaphore  until  a  V 
operation  is  subsequently  invoked  by  some  other  process.  The  term  then  reduces  to  a  value  that 
models  the  abstract  semaphore’s  value  just  before  the  P  would  have  returned.  A  *v  operation 
behaves  analogously.  Notice  how  the  term  is  reduced  to  the  return  value;  the  interaction  of  done 
and  outBide  strongly  resembles  exception  handling  in  Lisp.  The  value  returned  by  an  invocation 
of  a  p  or  V  operation  is  immaterial;  what  is  important  is  the  invocation’s  effect  on  the  semaphore’s 
value. 

Although  the  object  in  Figure  7  is  somewhat  muddied  by  the  star  operation’s  and  their  support, 
the  important  semantics  are  still  there.  The  conditional  equations  for  *p  and  p  ensure  a  nonnegative 
semaphore;  the  equations  allowing  *v  and  v  invocations  to  '’pass  by”  *p  and  p  invocations  model  V 
operations  that  execute  while  P  operations  are  blocked;  in  contrast,  the  lack  of  reordering  equations 
for  •p  and  p  invocations  enforces  the  FCFS  protocol. 

Finally,  consider  atomicity.  A  semaphore  implementation  usually  employs  an  atomic  test-and- 
set  instruction.  A  fact  for  OBJ3,  and  a  natural  assumption  for  any  eqnational  language,  is  that 
equation  application  is  atomic.  This  is  necessary  to  ensure  that  terms  remain  well  formed. 

5.5  Specification  of  Readers /Writers 

The  technique  used  for  the  SEMAPHORE  object  of  Figure  7  can  be  generalized  to  specify  the  Read¬ 
ers/Writers  problem.  For  concreteness,  the  database  proper  is  specified  as  an  associative  list; 
however,  it  is  strongly  sorted.  For  reusability,  the  key  and  item  sorts  are  specified  by  the  object’s 
parameters.  They  are  described  by  the  theories  in  Figure  8.  The  first  theory  requires  a  KEY  param¬ 
eter  to  provide  only  a  sort  Key  whereas  the  second  requires  an  ITEM  parameter  to  provide  a  sort 
Itea  and  a  constant  notf  ound.  Item  notf  ound  is  returned  by  an  unsuccessful  read  operation. 

Figure  9  is  a  parameterized  specification  for  the  Readers/ Writers  problem.  Its  various  parts 
are  described  in  the  following  paragraphs. 

Operations  *nav  and  new  simply  construct  an  empty  database,  shown  below. 

rw(0,0,M4> 

The  rv  operation  encapsulates  two  semaphorelike  counters  and  the  database  proper.  The  counters 
record  the  number  of  readers  and  writers  (resp.)  currently  accessing  the  database  proper;  eod 
abbreviates  "end-of-database”.  Operation  rac  stores  database  records.  When  a  record  is  written 
to  the  database,  its  key  and  item  components  are  stored  as  the  first  two  arguments  (resp.)  to  rec; 
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•kjact  UiBnS'niTXISCl  t:  UT.  I  > :  111113  U 

••rt  Sat»b>a«  . 
prataetiag  IIT  . 

■ahaart  Itaa  <  Batabaa*  . 

ap  aaaa  t  •>  Databaaa  . 

ap  ard  I  lay  Satabaaa  •>  Satabaaa  . 

ap  aar  i  lay  Itaa  Databaaa  ->  Databaaa  . 

ap  aaa  i  ->  Batabaaa  . 

ap  *4  1  lay  Batabaaa  •>  Batabaaa  . 

ap  ar  I  lay  Itaa  Batabaaa  •>  Batabaaa  . 

ap  la  t  lat  lat  Batabaaa  ->  Batabaaa  . 

ap  aa4  i  ->  Batabaaa  . 

ap  lac  :  lay  Itaa  Batabaaa  ->  Batabaaa  . 

ap  aidaat  t  Itaa  Batabaaa  •>  Batabaaa  . 
ap  aaraat  i  Itaa  Batabaaa  •>  Batabaaa  . 
ap  rdaat  >  Itaa  Batabaaa  ->  Batabaaa  . 
ap  araat  :  Itaa  Batabaaa  *>  Batabaaa  . 

ap  aatai4a  t  Batabaaa  •>  Itaa  , 

aar  B  i  Batabaaa  . 
aar  1  II  >  lay  . 

aar  1  XI  :  Itaa  . 

aar  11  t  lat  .  aaa  aaabar  af  raa4ara 

aar  n  ;  Xat  .  aaa  aaabar  af  arltara 

•••  Craata  a  aaa  batabaaa. 
a^  aaaa  a  ra(0,0.aad)  . 
aq  aaa  a  ra(0,0,aad)  . 

aaa  latar  tba  batabaaa. 

arbd.rain.n.B))  a  raCIl  a  x.n.arbd.B)) 
if  n  —  0  . 

eq  aard.X.radl.n.B))  a  radl.n  a  t.aard.I.B)) 
if  (11  a.  0)  aab  (BH  -a  0)  . 

eq  rbd.radl.n.B))  -  radl  a  t.n.Hd.B)) 
if  n  >a  0  . 

eq  ard,X,t«dB.n.B))  >  radl.BV  a  i.wrd.X.B)) 
if  (n  ■>  0)  aab  (I«  aa  0)  . 

aaa  Bait  the  batabaaa. 

aq  iv(n,n,aibaat(I,B>)  a  arbaatd.radl  -  I,n,B))  . 
aq  radl.n,aaraat<I,B))  ■  aaraat(I,ra<BB,IV  <•  I,B))  . 
aq  radl.n.rbaatd.B))  a  rvdl  -  I.BW.B)  . 
aq  ra(Bl,m, araat d,B))  a  ladl.lV  -  t.B)  . 


Figure  9:  The  Heuders/Writen  Spcdficution  Object  (1  of  3). 
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•••  Batara  raaulta. 

aq  aataida(ardaut(I,D)>  ■  I  . 
aq  aatsidaCaarautd.D))  *  I  . 

•••  Baad  travaraal  algor itha. 

aq  ardd.aad)  ■  ardoutCaetfoaad.aed)  . 
aq  ardCB.racCKl.lliD))  ■ 

If  B  ■>  El  thaa 

ardeat(Il,ra«(El,IliD)) 

alsa 

rac(El,Il.*rd(K.D)) 

fi  . 

aq  rd(E,aed)  ■  rdeatCaetfeaad.aed)  . 
aq  rd(I,rae(Il,Iltl»)  ■ 
if  E  —  II  thaa 

rdaat (11, rae(El, 11(B)) 

alsa 

rscdl  ,11  .rd(E,D) ) 

fl  . 

aaa  Hrita  traaarsal  algor itha. 

aq  aard.I.sad)  ■  aorsat(I,raed,X,sod))  . 
aq  aard.X.raedl.ll.O))  ■ 

If  B  aa  El  tkaa 

aarsat  <X  ,raed,X  ,0) ) 

alsa 

raedl.Xl.aard.X.O)) 

fl  . 

aq  srd.X.aod)  a  araat(l,rae(E,X,aod))  . 
aq  ard,X,racdl,Xl(D))  ■ 

If  E  -a  El  tkaa 

araat(l,raed,X(D)) 

alsa 

raedl.Xl.ard.X.O)) 

fl  . 

•••  Basalag  aqaatiaaa. 

aq  rscdl. Xl(ardsat(X,0))  a  ardaatd.rsedl.Xl.B))  . 
aq  rscdl. Xl.aaraatd.O))  ■  aaraatd. rscdl, Xl.P))  . 
aq  rocdl,Xl,rdaat(X,D))  a  rdaatd,racdl,Xl,D>)  . 

aq  rscdl, XI, arsatd.D))  a  araatd,racdl,Xl.D))  . 

aq  ard(Il,rdsat(X,D))  a  rdaat(X,ard(El,0))  . 

aq  arddl,sroat(X,0))  a  araat(X,arddl,ll))  . 

aq  aar(El,Xl,rdaat(X,D))  a  rdaatd.a*r(El,Xl,D))  . 

aq  •ar(El,Xl,arsat(l,D))  a  •raotd,awrdl,Xl,D))  . 

aq  r4dl.ardsat(X,D))  a  ardaat(X,rd(El,D))  . 

aq  rddl,aarsBt(X,D))  a  aarsat (X,rddl,D))  . 

aq  rd(El,rdsat(X,D))  a  rdsat(X,rddl,0))  . 

Figure  9:  The  Beaders/Wiiten  Specification  Object  (2  of  3). 


aq  r«(El,Brsat(X,D))  ■  •raat(X,rd(Il,0))  . 
aq  ar(Bl,Xl,ardsat(X,D))  ■  ordsat(X,ar(El,Xt,0))  . 
aq  ar(El,Xt, aaraatd ,D))  ■  •arsat(X,ar(Il,Xl,D>)  . 
aq  «r(El,Xl,rdsat(X.S))  ■  rdsBt(X,«r(Bl,Xl,D))  . 
aq  ar(Il,Xl,srsBt(X,D))  a  BrsBt(X,wr(El,Xl.B>>  . 

sads 


Figure  9:  The  Readers/Writert  Specification  Object  (3  of  3). 
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the  third  argmnest  it  the  rest  of  the  database.  As  cod  terminates  the  “list”  of  records. 

The  *rd,  ««r,  rd,  and  vr  operations  do  what  their  names  suggest;  their  uniform  coarities  are 
discussed  later.  The  *rdout,  *vrout,  rdout,  and  vrout  operations  are  necessary  for  decrementing 
the  rv  counters  upon  database  exit.  Specifically,  *rd,  *vr,  rd,  and  vr  “bubble  into”  the  database 
until  the  desired  key  or  eod  it  found,  whereupon  they  reduce  to  *rdout,  •vrout,  rdout,  and  vrout 
(resp.)  and  bubble  back  out  of  the  database,  decrementing  the  appropriate  counter  as  they  pass 
rv. 

The  use  of  outside  here  is  analogous  to  its  use  in  the  SEMAPHORE  object  from  Figure  7. 

READERS- WRITERS  defines  a  rather  curious  subtort  relation.  Specifically,  the  object  declares  a 
sort  Database  as  a  supersort  of  Item.  To  understand  why  this  is  necessary,  consider  the  coarities 
of  the  operatioxu. 

Intuitively,  a  read  should  return  an  item  and  a  write  should  return  nothing  (a  write  modifies 
the  database).  However,  an  OBJ3  operation  must  return  something,  so  both  *rd  and  evr  (hence 
•rdout  •vrout)  return  items;  erd  returns  the  item  read  and  evr  returns  the  item  written.  In 
contrast,  both  rd  and  vr  (hence  rdout  vrout)  must  return  a  database.  This  is  because  the  result 
returned  by  an  inconsequential  reader  or  writer  —  a  rd  or  vr  —  must  be  accessed  by  other  readers 
and  writers.^  Clearly  then,  rd,  vr,  rdout,  and  vrout  all  require  a  coarity  of  Database.  And 
even  though  the  coarity  of  vrd,  *vr,  vrdout,  and  •vrout  is  Database,  the  subsort  relation  Item 
<  Database  allows  them  to  return  items. 

The  four  conditional  equations  enforce  database-entry  synchronization;  compare  them  to  Equa¬ 
tion  1  on  page  101.  They  also  ensure  that  the  appropriate  counter  is  incremented.  Conversely,  the 
next  four  equations  decrement  a  counter  when  an  invocation  leaves  the  databaise.  Notice  how  a 
rdout  or  vrout  disappears  after  it  passes  rv.  However,  a  erdout  or  evrout  eventually  bubbles 
to  the  outside  of  the  term  where  one  of  the  next  two  equations  —  those  for  outside  —  finish  the 
reduction.  Next  come  equations  that  implement  the  typical  traversal  algorithms  for  a  read  or  write 
operation.  The  remainder  of  the  equations  allow  certain  operations  to  pass  by  each  other.  If  more 
sophisticated  scheduling  is  desired,  additional  equations  of  a  similar  nature  could  be  used  (e.g.,  to 
reorder  read  and  write  invocations).  Alternatively,  rv  could  be  given  an  additional  argument  —  a 
list  of  blocked  invocations  —  that  would  be  ordered  according  to  the  scheduling  discipline. 

The  number  of  equations  would  be  greatly  reduced  if  OBJ3  supported  second-order  equations. 
The  OBJ3  alternative  —  parameterization  and  instantiation  —  is  hardly  worth  the  effort  here. 

In  order  to  test  a  READERS-WRITERS  database,  key  and  item  views  are  needed.  The  views  in 
Figure  10  are  for  a  database  whose  keys  are  alphanumeric  identifiers*  and  whose  items  are  natural 
numbers  (zero  represents  a  nonexistent  item).  An  izutantiation  and  some  sample  reductions  are 
also  shown. 

5.6  Verification  of  the  Readers/Writert  Invariant 

In  the  last  section,  OBJ3  was  used  to  specify  a  concurrent  programming  problem  and  to  test  the 
specification  on  a  few  samples  of  input  data.  Although  bugs  found  during  testing  are  guaranteed 
to  be  bugs,  testing  is  not  guaranteed  to  find  all  the  bogs.  Program  verification  strives  to  be  more 
thorough.  Accordingly,  this  section  describes  OBJ3’s  use  as  a  verification  tool.  In  particular,  we 
prove  that  the  operations  provided  by  the  READERS-VRITERS  object  of  Figure  9  maintain  the  truth 
of  Equation  1  on  page  101. 

*Witk  regard  to  the  rcaalt  of  a  redaetioa,  a  rd  ie  a  ao>ep,  bat  a  ar  may  have  aa  effect. 

*qZ0L  proeidea  "qaali/ied  loag  ideatiiien*  (via.,  LiSP  aymbob). 
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vi««  UT'TO-qXOL  froB  lET  to  QIOL  ia 
aort  laj  to  Id  . 

oad« 

oioo  ITn-TO-liT  fraa  inn  to  lAT  la 
•art  Itaa  to  lat  . 

Of  Mtfoaad  to  0  . 

oad* 

■oka  IK  la  ■IABnS-llllTBSCUT*TO-qiOL.Xnil-TO-ll^)iaM>ject. 


rodoca  la  Ul  t  aBtalda<ard(>a.Br<'a.l,aoa))) 
roar Itaa:  33 
roaalt  lalat:  1 


rodaeo  la  tH  i  oatalda<ard(*a«ar(>b,t,aaa>)) 
roorltaai  34 
roaalt  tara:  0 


radaea  la  tH  t  aatalda(ard('a.ar(>a.3,ar(*a,l.aaa>)» 
roar Itaa I  34 
raaalt  lalati  3 


radaea  la  IH  <  aotalda(ard<>a.ar<>a.3.ar(>b,l,aaa)>)> 
roar Itaa s  40 
raaalt  lalat:  3 


radaea  la  W  !  aataldo<ard(>b.ar('a,3.ar(>b,l.aaa>>» 
roarltaa:  3d 
raaalt  lalati  1 


radaea  la  IH  i  aotal4o(aor('b.3,ar( 'a.l.arC ’b.l.aaa)))) 
roarltaa:  3S 
roaalt  lalati  3 


radaea  la  U  i  aatalda(ar(>b,3.ar(>a,3.aar<>b.l.aoa)))) 
raarltaai  40 
raaalt  lalat:  1 


radaea  la  H  i  oatalda(or(>b,3.ard(>b,ar(>b.l.aoa)>» 
raarltaai  3S 
roaalt  lalati  i 


radaea  la  IH 
raarltaai  30 

roaalt  lalat: 


aatalda(ar( 'b.I.rdC  >b.oar(  >b.l  ,aaa»» 


(b);  Rddvetiau. 


Figure  10:  Initastiating  uud  Tettisg  »  Dutubwe. 
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•kj«ct  DXVIOl  ia 
pra«actia(  UT  . 

divida  41*  t  Kat  Kat  ->  ftat  . 
ap  aadaftaad  :  •>  lat  . 

*ar  I  T  t  lat  . 

apa  s*ar  fwtr  :  ->  lat  .  •••  Variabla  aparatlaaa 

aq  4ivi4a<Z,T)  ■ 
if  T  —  0  thaa 
wdafiaad 
alaa 

41*(Z.T) 

<1  . 

aq  4i*(Z.T)  -  Z  /  T  . 

•Ma  (a);  Object 


radaca  la  DXTIOl  i  dl*ida<a*ar,r«ar) 

raaritaai  4 

raaalt  Bati  aaar  /  eilat>latat(rrar) 


(b):  Badvetioa. 


Fifore  11:  A  Pint  Attcxnpt  at  tJnixg  Vaziable  Opcratioxu. 


Tlxez«  are  three  xxiaia  etep*  in  the  verificatioxi.  First,  a  proof  object  is  coxutructed  froxn  the 
Mped£cetJoa  object  ixi  Figore  9.  This  proof  object  is  then  ixutantiated*  and  angxnented  with  a 
predicate  on  sort  Database  expressing  the  Readers/Writers  invariant.  This  predicate  is  then  used 
with  a  form  of  stmctnral  induction  to  show  that  serviced  invocatioxu  maintain  the  invariant. 

5.6.1  Coxistruction  of  the  Proof  Object 

The  transformation  from  specification  object  to  proof  object  ia  necessary  because  the  0BJ3  inter¬ 
preter  was  not  designed  to  be  a  theorem  prover;  modificatioxu  that  elixxiinate  the  need  for  this  step 
are  considered  later.  The  fundamental  problem  is  that  the  interpreter  can  only  reduce  variable-free 
temu  (i.e.,  groxmd  terms).  There  exist  more  powerful  reductioxxs  systexxu  —  unification  systems  — 
that  can  reduce  terms  containing  variables  [Lel88],  but  such  flexibility  is  actually  uzinecessary  here. 
The  trick  is  to  replace  variables  in  a  term  with  vaxiahie  operations  [GHM78].  A  variable  operation 
is  a  new  coxutant  operation  whose  coarity  is  the  sort  of  the  variable  it  replaces.  Alternatively,  a 
variable  operation  can  be  given  an  integer  argument  thereby  allowing  it  to  replace  any  number  of 
variables  of  that  sort. 

Unfortxuiately,  a  term  containing  variable  operatioiu  does  not  always  reduce  as  expected. 
Consider  the  rudimentary  proof  object  and  reduction  in  Figure  11,  where  variables  X  and  Y  are 
replaced  by  operatioxu  xrvar  and  yvar.^’’  The  problem  is  that  OB  J3’s  built-in  equality  operation, 
.M.,  returxu  false  because  yvar  is  not  syntactically  equal  to  0.  The  solution  is  to  replace  the  built- 
in  equality  operation  with  a  symhoiic  eqaeJity  operation,  .as*..  The  symbolic  equality  operation 
reduces  to  true  if  its  arguments  are  equal,  but  does  not  reduce  to  false  (i.e.,  it  does  not  reduce 
at  all)  if  its  arguments  are  unequal. 

Unibrtuxiately,  the  symbolic  equality  operation  caiues  yet  another  problem,  as  dcmoxutrated 
in  Figure  12.  This  time,  the  culprit  is  the  lasy  if  .thea.else_f  i  operation.  Its  evaluation  strategy 
directs  the  interpreter  to  reduce  the  if  subterm  first.  U  it  reduces  to  true,  the  operation  reduces 
to  the  than  subterm;  if  it  reduces  to  false,  the  operation  reduces  to  the  else  subterm*,  but  if  it 

of  s  pazsactcnMd  ebjdct  aff«n  th«  edditkesl  edvaatsgc  of  pteef  maohilitj.  I^ztbcnaozc,  it  ba* 
boss  sbowa  to  ba  astbosMticallr  aoud  [GogSS].  Uafartoaotair,  tba  OBJ3  iatarpratar  euaot  pariem  radactioat 
is  tba  eoetazt  of  a  ponaatansad  objaet.  Tbarefaia,  Mtoowtisf  seeb  a  vandcatioo  aoaas  dificalt. 

**Tba  atiaafa  leokiai  r:IUt>lsSat  oparatioa  ia  a  /atraet,  past  of  OBJS’a  sabaortias  aadaaiam.  Isaore  it. 
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•bjact  OlfIDE  ia 

protaetiBf  UT  «  PBOOF-TttmiCUT]  . 
aps  dialda  dl*  :  Bat  Bat  ->  Bat  . 
ap  aadafiaad  :  ->  Bat  . 
var  1  T  :  Bat  . 

apa  avar  p«ar  :  ->  Bat  .  aa*  Varlabla  oparatleaa 
aq  diTida(X,T)  > 
if  T  aaa  0  than 

■adafiaad 

alaa 

di*(Z.T) 

fl  . 

aq  diad.T)  ■  Z  /  T  . 

aado  (a):  Object 


radaea  ia  DIVIDE  i  divida(a*ar,ytrar) 
raarltaa:  1 

rasalt  Bati  if  yvar  aaa  0  tbaa  aadafiaad  alaa  diWaayjj|^B^j>^j^i 


Figure  12:  Adding  n  Symbolic  Equality  Operation. 


abjaet  DIVIDE  ia 

prataetiag  BIT  *  PBOOP-TBUritBATl  . 
apa  divide  div  i  Bat  Bat  ->  Bat  . 
ap  aadafiaad  i  ->  Bat  . 
var  Z  T  :  Bat  . 

apa  avar  pvar  )  ->  Bat  ,  aaa  Variable  aparatiaaa 
aq  dividatZ.T)  - 
aif  T  aaa  0  tbaa 
aadafiaad 

alaa 

divCZ.T) 

fl  . 

aq  div(Z.T)  a  Z  /  T  . 

(a):  Object 


radaea  la  DIVIDE  i  dlvida(avar,yvar) 
raarltaa I  2 

raaalt  Bati  aif  jvar  aaa  o  tbaa  aadafiaad  alaa  ^ 


Figure  13:  Adding  nn  Enger  Conditional  Operation. 


reduce!  to  neither  true  nor  false  (e.g.,  yrar  ■s«  0),  the  if _tben_elBe_f i  operation  remains  in 
the  term.  In  the  first  two  cases,  the  selected  subterm  is  subsequently  reduced;  but  in  the  latter 
case,  neither  subterm  is  reduced,  even  though  both  may  be  reducible.  The  solution  is  to  replace 
the  built-in  conditional  operation  with  an  eager  eonditiona/  operation,  eif.tben_el8a.fi.  The 
eager  conditional  operation  has  an  evaluation  strategy  that  directs  the  interpreter  to  reduce  all 
three  arguments*^  before  attempting  to  select  a  subterm. 

The  final  version  of  the  proof  object  is  shown  in  Figure  13.  Symbolic  equality  and  eager 
conditional  operations  produce  a  more  satisfying  result. 

Syntax  and  semantics  for  .as*,  and  eif.tboa.else.fi  are  provided  by  PROOF-BOOL  and 
PROOF-TRUTH.  These  are  objects  that  roughly  correspond  to  OBJS’s  buDt-in  BOOL  and  TRUTH  ob¬ 
jects.  Figure  14  shows  the  signature  of  both  objects.  Section  5.10  lists  them  in  their  entirety. 
PROOF-TRUTH  is  parameterised;  it  can  be  instantiated  for  comparison  and  selection  of  elements  of 
any  sort.  PROOF-BOOL  is  viTniUr  to  —  but  more  sophisticated  than  —  PROOF-TRUTH  [BOOL] .  Notice 
how  important  overloading  is.  Without  it,  a  different  operation  name  would  be  needed  for  each 

Azgameats  an  ndaecd  kft-t»-rigbt,  bst  suet  aa  OBJS  epetatioa  eaaaet  caaM  iida-efiiKte,  the  cvalaatioa  otdet 
ia  aaimportaat. 
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•kj«e«  noor>uoL  i* 

rr*t«etla(  nvn*TAUIX  . 

^t«etiaf  MOL  . 

•p  :  Mol  Oeol  Bool  •>  lael 

[otrotofy  (1330)  gothor  (>  t  k)  proe  0]  . 
op  .000.  :  Bool  Bool  ->  Bool  [otrotogy  (130)  proe  tl]  . 


oBjoet  PBOOr-TBOnU  I  >  TBIV]  lo 
protoetlag  TBOTB^fALOE  . 
protoctiag  noOF-MOL  . 

•p  olf_tkoa.oloo.fl  :  Bool  Bit  Bit  •>  Bit 

Catratogy  (1  3  3  0)  gotkor  (B  B  B)  proe  0]  . 
op  .aoo.  1  Bit  Bit  •>  Bool  Catratogy  (1  3  0)  proe  SI]  . 


Figure  14:  SignBtnres  of  PROOF-BOOL  and  PROOF-TRUTB. 

sort.  Also  noteworthy  are  the  cvalnation  strategy  for  •if.then.elae.f i  and  the  single  equation 
for  .■■■_.  In  comparison,  the  built-in  TRUTH  object  pves  if_than_elsa_f  i  the  attribute  strategy 
(1  0)  and  uses  a  built-in  equation  (i.e.,  Lisp  code)  to  always  reduce  a  to  true  or  false. 

The  elided  portions  of  PROOF-BOOL  and  PROOF-TRUTH  are  primarily  the  familiar  tautologies. 
Unfortunately  however,  some  boolean  simplification  rules  are  schematic  or  higher  order.  They 
represent  an  infinite  number  of  equations  [GHM78].  For  example,  the  ‘logical-substitution"  rule 
says  that  all  occurrences  of  an  if  subterm  can  immediately  be  reduced  to  true  or  false,  if  the 
occurrence  is  in  a  corresponding  then  or  else  subterm  (resp.)  —  regardless  of  how  deeply  nested 
the  occurrence  is.  In  addition,  since  the  equation  sets  are  logically  incomplete,  special-purpose 
equations  are  often  necessary.  Consequently,  equations  are  added  as  needed. 

The  final  step  in  transforming  a  specification  object  into  a  proof  object  is  to  remove  conditional 
equations.  This  is  necessary  because  the  boolean  condition  associated  with  a  conditional  equation 
probably  uses  which  means  it  will  not  reduce  properly  in  the  presence  of  variable  operations. 
A  conditional  equation  of  the  form 
1  ■  r  If  b 

can  be  transformed  into  a  regular  equation  of  the  form 
1  ■  If  6  tkaa  T  alsa  I  f  1 

allowing  variable  operations  and  the  symbolic  equality  and  eager  conditional  operations  to  be 
used  as  before.  The  transformed  equation  is  recursive.  Operationally,  it  implies  a  nonterminat¬ 
ing  reduction  sequence.  This  is  especially  evident  cmiaidering  the  eager  evaluation  strategy  for 
olf.then.olse_f  i.  A  proof  tool  that  prevents  this  unpleasant  behavior  is  described  later. 

Figure  15  is  the  proof  object  that  results  from  applying  the  abovementioned  transforma¬ 
tions  to  the  specification  object  in  Figure  9.  Notice  the  systematic  convention  for 

variable  operations,  the  multiple  mstantiations  of  PROOF-TRUTH,  the  equations  wwig  operations 
from  PROOF-TRUTH,  and  the  erstwhile  conditional  equations.  Also,  remember  that  the  object  is  still 
nninstantiated. 
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•kjaet  lums-njinsu  lET,  1  ::  ITEM]  !• 

••rt  Databu*  . 
prataetiag  IIT  . 
sabaort  Itaa  <  Oatabaaa  . 

ap  aaaa  :  ->  Batabaaa  . 

•p  ard  I  Eaj  Databaaa  ->  Batabaaa  . 
ap  aar  i  Eay  Itaa  Batabaaa  ->  Batabaaa  . 

ap  aaa  i  •>  Batabaaa  . 

ap  Id  t  tap  Batabaaa  ->  Batabaaa  . 
ap  ar  I  Bap  Xtaa  Batabaaa  •>  Batabaaa  . 

ap  n  I  lat  lat  Batabaaa  •>  Batabaaa  . 

ap  aad  :  ->  Batabaaa  . 

ap  rae  i  Bap  Itaa  Batabaaa  ->  Batabaaa  . 

ap  ardaat  :  Itaa  Batabaaa  ->  Batabaaa  . 
ap  aaraat  :  Itaa  Batabaaa  •>  Batabaaa  . 
ap  rdaat  i  Itaa  Batabaaa  ->  Batabaaa  . 
ap  arant  i  Itaa  Batabaaa  •>  Batabaaa  . 

ap  aatalda  t  Batabaaa  •>  Itaa  . 

•••  fariabla  aparatiaaa. 
ap  dvar  i  ->  Batabaaa  . 
ap  kaar  t  •>  Bap  . 
ap  iaar  t  •>  Itaa  . 
ap  araar  i  •>  lat  . 
ap  aavar  t  >>  lat  . 

•••  Praaf  taala. 

prataetlBf  noOP'TVm  [Batabaaa]  . 
pratactlaf  nOOF-TBVnClap]  . 
prataetlaf  FBOOr-TBOn[Itaa]  . 
pratactlaf  noor-TOTBClat]  . 

car  B  :  Batabaaa  . 
rar  B  Bt  i  Bap  . 
car  I  II  I  Itaa  . 

rar  IB  i  lat  .  aaa  aaabar  af  raadara 

aar  n  i  lat  .  aaa  aaabar  af  arltara 

•••  Craata  a  aaa  databaaa. 
a«|  aaaa  ■  ra(0.0,aad)  . 
aq  aaa  a  ra(«,0.aad)  . 

aaa  ftitar  tha  databaaa. 

aq  ard(I,ta(BB,BH.B))  - 
alf  III  aaa  0  thaa 

Figure  15:  The  Rceden/Writen  Proof  Object  (1  of  3). 
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r«(n  «  t.lH.«rd(I.O)) 

•rd(I.r«(n.n.O)) 

fi  . 

•q  •n<t,I.r«(n.W.D»  - 

•If  (n  0)  aad  (IN  ■■■  0)  tk«a 
rv(n.n  ♦  l.and.l.B)) 

•ntt.I.ndk.m.D)) 

fi  . 

•q  r«(K.t«(n.n.B))  - 
•if  m  0  tkos 

n(n  «  t.n.H(B.O)) 

•!•• 

rtd.nCII.n.B)) 

fi  . 

•q  *rd.Z.n<n.n.B))  - 

•if  (n  ■•■  0)  aad  (BH  ■•■  0)  tkaa 
ndt.n  *  l.vrd.l.D)) 

•!•• 

•rd.X.ndt.n.B)) 

fi  . 

•••  bit  tk«  databaa*. 

•q  n<n.I«.ardaata.B))  •  ardaatd.ndk  -  i.BV.B))  . 

•q  rwdt.lW.avraatd.B))  ■  avrvatd, ndt.n  •  i.B))  . 

•q  n(n.n,rd«atd.B>)  ■  ndt  •  l.n.B)  . 

•q  n<n.n,«natd,B))  ■  n(n.n  •  l.B)  . 

•••  beam  nsalta. 

•q  •atalda<ard«atd,B))  ■  I  . 

•q  •ataidainraatd.B))  ■  I  . 

•••  bad  travanal  algaritka. 

•q  ardd.avd)  ■  •rd«at(aatfa«ad,«ad}  . 

•q  ardd.racdl.Il.B))  ■ 

•if  K  ■•«  li  tkaa 

ardaat  dl  .raedi ,  li  ,B) ) 

•Xaa 

ncdl.Il.ardd.B)) 

fi  . 

•q  add. aad)  ■  Tdaat(aatfaaad.aad>  .  ' 

•q  rdd.raadl.Xl.B))  ■ 

•if  K  ■•■  Bi  tkaa 

adaat  (11  .racdl .  XI  ,B)  ) 

•Ua 

ncdi.Xl.rdd.B)) 

fi  . 

•••  Writa  taaaanal  alfaritka. 

Fjfnrc  15:  The  Retden/Writen  Proof  Object  (2  of  3). 
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•q  •«r(I,l,«ed)  ■  ••raat(l,r«e(I.l,Md)>  . 

•q  ••r(K.I.r*c(Kl,Il,D))  ■ 

•if  I  ■■■  It  tk«B 

••raatd.racd.l.B)) 

•!•• 

fl  . 

•q  crdtltaod)  ■  •raat(l,r«ed,I,«ad))  . 

•q  ard.I.racdl.IltO))  ■ 

•if  I  ■■■  El  than 

•raotd.raed.l.D)) 

•laa 

racdl.ll.ard,l«D)) 

fi  . 

•••  Paaaiag  aqaatlaBa. 

aq  raedl.li>*rdaatd,D))  •  ardaatd.raedl.Il.O))  . 
aq  raedl(li<**raatd,0))  ■  aaraatd.raedtili.O))  . 
•q  raedltIitrdaat(l,D))  ■  rdaatd,rae(El,Il>D)>  . 
•q  raedl.IifVraatd.D))  ■  araatd.raedl.IltD))  . 

•q  arddltrdaatd.O))  ■  rdaatd.arddl.O))  . 

•q  arddl.araatd.O))  ■  araatd.arddltl)))  . 

•q  aardl.Iitrdoatd.O))  ■  rdaatd,aardl,litB>>  • 

•q  aardl.IitVravtd.D))  ■  araatd.aardl.IltO))  . 

•q  rddlt*rdaatd,D))  •  ardaatd.rddl.D))  . 

•q  rddl,«araatd,D))  •  aaraatd.rddl.D))  . 

•q  rddi.rdaatCI.D))  ■  rdaatd.rddl.D))  . 

•q  rddl.araatd.O))  ■  araatd.rddl.O))  . 

•q  ardl.Zl.^rdaatdfD))  ■  •rdaatd,ardl,ll,0))  . 

•q  ardl.Il.aaraatd.D))  ■  aaraatdiardl.lltO))  • 

•q  ardlrll.rdaatd.D))  ■  rdaatd.ardl.Il.D))  . 

•q  ardltll.araatd.D))  ■  araatd,ardl,Il,D))  . 

•ada 


Figure  15:  The  Readeri/Wiiters  Proof  Object  (3  of  3). 
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•bjcet  M  is 

ssisg  UAOCU-niTEBSIlET-TO-QlOL.ITDI-TO-UT}  . 

•••  Proof  tools. 

op  lav  :  Ootaboss  •>  Bool  . 
asiag  PBOOF-IIT  . 

BSiag  PBOOF-CASE  •  (sort  Sort  to  Ostsboso,  op  p  to  in«)  . 

•oo  loadors/Hritsrs  lavoriaat. 
var  0  :  Databaas  . 
oar  It  n  ;  lat  . 
oq  iBo(ro(n,IV.D)>  ■ 

((■I  >so  0)  aad  (lU  >ao  0)  aad  (IK  <sa  1)  aad 
((It  oso  0)  or  (lU  OBO  0))>  oaa  tins  . 

aado 

Figure  16:  The  Readers /Writer*  Invariant  Property. 

5.6.2  Conetruction  of  the  Invariant 

The  next  step  in  the  verification  is  to  translate  Equation  1  on  page  101  into  an  OBJ3  equation. 
This  equation  is  part  of  the  prediate  object  RW  in  Figure  16.  At  in  Figure  10,  RV  it  an  instantiated 
database  mapping  identifiers  to  natural  numbers.  However,  the  source  of  the  instantiation  is  the 
proof  object  from  Figure  15.  Operation  inv  is  a  predicate  on  tort  Database;  its  equation  defines 
it  to  be  true  iff  the  invariant  is  true.  RW  also  imports  PROQF-INT  and  PROOF-CASE.  The  signatures 
of  these  proof  tools  are  shown  in  Figure  17;  Appendix  5.10  lists  both  in  their  entirety.  PROOF-INT 
provides  symbolic  relational  operations  on  integers  that  are  similar  in  purpose  to  ."S*..  Likewise, 
it  contains  some  familiar  and  some  special-purpose  tautologies.  PROOF-CASE  provides  a  “case- 
analysis”  rule  [GHM78].  This  is  an  example  of  a  second-order  rule;  it  is  instantiated  by  sort  and 
operation  renaming.^^  This  is  one  of  OBJS’s  module-expression  constructs. 

5.6.S  Induction  Scheme 

Having  constructed  the  proof  and  predicate  objects,  terms  whose  reductions  verify  the  invariant  can 
now  be  formulated.  The  approach  resembles  structural  induction,  a  generalization  of  induction  over 
the  integers  [GHM78].  First,  we  prove  that  the  invariant  holds  for  a  newly  constructed  database 
(the  basis).  Hext,  we  assume  properties  of  an  existing  database  (an  inductive  hypothesis)  and 
prove  that  an  invocation  trying  to  “enter”  the  database  preserves  the  invariant  (an  inductive  step). 
Finally,  we  assume  properties  of  an  existing  database  (another  inductive  hypothesis)  and  prove 
that  an  invocation  trying  to  “exit”  the  database  preserves  the  invariant  (another  inductive  step). 
Both  star  and  nonstar  operations  must  be  considered.  This  doubles  the  number  of  reductions  in 
the  proof,  but  half  of  them  are  essentially  reruns.  Before  starting,  however,  one  more  proof  tool  is 
necessary. 

Recall  that  the  transformation  from  a  conditional  equation  to  a  regular  equation  introduced 
tail  recursion.  Also,  notice  that  some  of  the  traversal  equations  from  Figure  9,  hence  Figure  15, 
are  recursive.  In  order  to  avoid  infinite  reduction  sequences,  this  recursion  must  be  controlled.  The 
solution  is  to  use  a  modified  veruon  of  the  interpreter  that  provides  a  user-callable  Lisp  function 
recurs ion-lialt,  shown  in  Figure  18.  Arguments  are  bound  to  parameters  according  to  Lisp’s 
“by  keyword”  parameter-passing  mechanism.  Some  defaults  apply.  If  the  :obj  keyword/argument 
pair  is  <»mitted,  all  operations  with  the  specified  name  are  recursion  limited.  If  the  :op  pair  is 

^CoaTcatioaal  parametensatioa  aad  iaatsatiatioii  did  not  acem  to  work  kere. 
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•bjaet  PKOOF-IIT  ia 

pratactiag  nOTH-VALUE  . 
protaetiag  XVT  . 
prataetiBg  PlOOF-TIOTHCirr]  . 

ap  .<a.  I  lat  lat  ->  •ool  [prae  61]  . 
ap  .<aa.  :  lat  lat  ->  Baal  [prac  61]  . 
ap  _>a.  t  lat  lat  ->  Baal  Cprae  61]  . 
ap  .>sa.  I  lat  lat  ->  Baal  Cprae  61]  . 


aada 


abjaet  PBOOF-CiSB  ia 
aart  Bart  . 

ap  p  :  Bart  ->  Baal  . 

ap  alf_thaa.alaa.fi  i  Baal  Bart  Bart  ■*>  Sort  . 
ap  aif_thaa.alaa.fl  i  Baal  Baal  Baal  •>  Baal  . 

var  B  I  Baal  . 

Tar  B1  B3  i  Bart  . 

aq  p(alf  B  thaa  Bl  alaa  83  fi)  ■ 
aif  B  thaa 

p(St) 

alaa 

p<S3) 

fi  . 

aaBa 


Figure  17:  SiguatureE  of  PROOF-IHT  and  PROOF-CASE. 


(raearalaa-liait 
lahj  <abj*aaaM>  istriaf 

lap  <ap-aaM>  latriag 

illait  <liait>)  liatagar 


Figure  18:  RecurBios  Limiting. 
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(»):  RcdnctioM. 


r«d«c«  !>«<•••«)  . 
r*4«c«  lav<a«>)  . 


r«4«e«  1b  tH  :  iBv(*B««> 
ravritaa:  13 
rasalt  ■•el:  tn« 


r«d«e«  la  M  :  iBv(a*«) 
raarltaa:  13 

I  raaalt  ■••I:  tra* 


omitted,  all  operations  in  the  spediied  object  are  recursion  limited.  If  the  : limit  pair  is  omitted, 
the  limit  is  removed. 

The  modified  interpreter  maintains  a  list  of  recnrsion^limited  operation  names.  Just  before 
each  reduction  step,  the  top  operation  of  the  subterm  to  be  reduced  is  compared  to  those  on  the 
list.  If  a  match  is  found,  the  current  recursion  depth  for  that  operation  is  compared  to  its  limit. 
If  the  limit  has  been  reached,  the  subterm  is  marked  as  reduced;  otherwise,  the  current  recursion 
depth  for  that  operation  is  incremented  and  subterm  reduction  proceeds. 

Figure  19  shows  two  reductions  proving  that  the  invariant  holds  for  a  newly  constructed 
database.  No  recursion  limiting  is  necessary  here.  The  equation  for  «nsu  (or  nau)  is  applied, 
then  the  equation  for  inv.  The  rest  of  the  reduction  sequence  is  straightforward  simplification  — 
a  process  called  jitteziag. 

Figure  20  shows  an  inductive  hypothesis  and  four  reductions  proving  that  the  invariant  is 
preserved  by  an  invocation  trying  to  enter  the  database.  OBJS’s  ev  keyword  causes  the  Lisp 
expression  following  it  to  be  evaluated.  This  and  recursion-limit  are  used  to  avoid  the  recursion 
problems  discussed  earlier.  For  tidiness,  the  limits  are  removed  when  they  are  no  longer  needed. 
RUl  imports  the  predicate  object  RW  from  Figure  16  and  adds  the  indnctive-h3rpothe8is  equations. 
The  assumption  is  that  the  current  state  of  the  database  satisfies  the  invariant.  In  other  words, 

lav ( r* ( arvar ,a«var ,4var ) ) 

is  true.  Now  what  we  want  to  do  is  show  that  a  *rd,  rd,  vur,  or  «r  invocation  on  the  database 
preserves  the  invariant.  The  four  terms  to  be  reduced  are  constructed  accordingly.  In  the  reductions, 
the  equation  allowing  the  invocation  to  pass  by  n  is  applied  first,  leaving  a  large  ail _then_el8e.l i 
subterm  surrounded  by  inv.  Case  analysis  then  distributes  inv  to  the  then  and  else  subterms. 
The  rest  is  pttering. 

Notice  that  none  of  these  terms  reduce  to  true,  as  before.  This  is  because  a  counter’s  current 
value  may  prevent  an  invocation  from  entering  the  database.  In  essence,  the  synchronisation 
provided  by  conditional  equations  in  a  specification  object  translates  to  equational  polling  in  a 
proof.  These  reduction  results  arc  interpreted  as  follows.  If  an  invocation  is  allowed  to  enter  the 
database,  the  invariant  is  preserved;  but  if  it  is  not  allowed  to  enter,  it  blocks  until  it  can.  Clearly, 
this  is  only  partial  correctness.  However,  techniques  for  proving  finite  tennination  (i.e.,  that  an 
equation  set  leads  to  reductions  that  always  terminate)  are  well  known  [GogSO]. 

Figure  21  shows  two  inductive  hypotheses  and  four  reductions  proving  that  the  invariant  is 
preserved  by  an  invocation  trying  to  exit  the  database.  This  proof  is  simpler  than  the  database- 
entry  proof  due  to  a  general  fact  that  a  process  has  no  reason  to  block  when  giving  up  a  resource. 
Both  inductive  hypotheses  import  RUl,  the  inductive  hypothesis  from  Figure  20.  Thus,  RU2  and 
RU3  represent  additional  facts  that  we  assume  are  true  when  a  reader  or  writer  (reap.)  is  in  the 
database.  Assuming  that  a  reader  is  in  the  database,  there  must  be  at  least  one  reader  and  no 


(b):  RetnlU. 

Figure  19:  The  Bases  Proofs. 
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•bj«et  Ml  !■  uiB(  M  . 

•q  arrar  >•>  0  ■  tn«  . 

•q  Bwar  >•■  0  ■  tna  . 

•q  Mvar  <•■  t  ■  traa  . 

•q  araar  0  ar  aaaar  aaa  0  ■  traa  . 

aado 

av  (raearaiaa*liait  labj  "lUDlM-aiim"  lap  “ar^**  illalt  1> 
aa  (raearaloa-liait  labJ  ■■lUOns-HlITnS"  lap  *'rd**  iliait  1) 
radaea  iaa(ard(kTar.Ta<araartBaaar,daar)))  . 
radaea  lav(rd<kvar(ra(arTar,aa¥ar,d*ar)))  . 
aa  (raearaiaa-llait  labj  “ISIOnS-WUlPS*'  tap  ‘’ard") 
aa  (racaralaa-llalt  tabj  "■SABEU-niTSkS"  tap  *‘rd‘‘> 

aa  (raearalaa-lialt  labJ  “UiOBIS-WITBlS**  tap  “aar"  tllait  1) 
aa  (raearalaa-lialt  tabJ  ‘’lUilCU-iaiTSlS"  tap  “ar"  tllait  1) 
radaea  iaa(aer(kaar, laar.raCaraar, aaaar, daar)))  . 
radaea  lBa<er(ka4r,iaar,ra(araar,aaaar,daar)))  . 
aa  (raearalaa-lialt  tabj  “UiOEtS-niTSkS"  tap  “aar”) 
aa  (raearalaa-lialt  tabj  “UASEkS-niTSkS"  tap  ‘(i^)R4>dactioaa. 

radaea  la  BHl  i  laa(ard(kaar,ra(Braar,Baa4r,daar))> 
raarltaat  IT 

raaalt  Baalt  aif  aaaar  aaa  0  thaa  traa  alaa  iBa(ard(kaar,ra(araar,Baaar, 
daar»)  fi 


radaea  la  Ul  t  lBa(rd(kaar,ra(araar, aaaar, daar))> 
raarltaat  17 

raaalt  Baalt  alf  aaaar  "a"  0  tkaa  traa  alaa  iBa(rd(haar,ra(araar,Baaar, 
daar)))  fi 


radaea  la  BUI  t  iBa(aar(kaar,laar,re(Braar, aaaar ,daar>)> 
raarltaat  35 

raaalt  Baalt  alf  aaaar  aa"  0  aad  araar  aa"  0  thaa  traa  alaa  laa(aBr( 
kaar,laar,rB(araar,Baaar,daar)))  fi 


radaea  la  BHl  t  iaa(ar(kaar,laar,ra(araar,aaaar,daar))) 
raarltaat  35 

raaalt  Baalt  aif  aaaar  aaa  0  aad  araar  aaa 

kaar,laar,ra(araar, aaaar, daar)))  fl 


0  thaa  traa  alaa  laa(Br( 
(b):  Baavlte. 


Figure  20:  The  Inductive  StepB  for  Dutabase  Entry. 
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•kjMt  m  i« 
wU(  ui  . 

v*r  n  n  I  lat  . 

arvar  >•  0  ■  tn«  . 

•q  awar  aaa  0  ■  traa  . 

aq  ar4aat(ivaa,n<ll,n>4*ar))  ■  ra(n,lll,4«ar)  . 

aada 

radaea  iav<r«(Brrar,Bavar,*rdaat<iaar,4var)))  . 
radaea  la«(ra(aiirar,aB«ar,rdaBt<i«ar,d«ar)>)  . 

akjaet  U3  ia 
aalaf  IHl  . 
aar  n  n  :  lat  . 
aq  araar  aaa  o  a  traa  . 
aq  aavar  >a  0  a  traa  . 
aq  aaaar  <aa  t  a  traa  . 

aq  aaraat(laar,rB<n,n,d*ar))  ■  ra<lt,IH,d«ar)  . 

aada 

radaea  iaa(ra<araar.a*aar,a«raat(laar.daar)))  . 

radaea  iaa(r«(araartaaaartaraat<laar,daar)))  .  (^y,  Bedaetioas. 


radaea  ta  U2  :  laa<ra(Braar.aevar.ardaat(laar,dvar>)> 
raerltaai  1C 

raaalt  taali  traa 


radaea  la  U3  :  iav<re(araar.Baaar,rdaat(l*ar.d*ar))) 
raerltaa:  14 

raaalt  laal:  traa 


radaea  la  1113  :  laa(ra<Braartaaaar)aaTaat(lTar,daar))) 
raerltaa:  19 
raaalt  Baal:  traa 


radaea  la  W3  i  laT(re<arrar,aeaar,wraat<lvar,d«ar>)) 
raerltaa:  18 
raaalt  Baal:  traa 


(b):  Reealta. 


Figure  21:  The  indnetive  Stepf  for  DaUbue  Exit. 
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writers  is  the  database.  Assuming  that  a  writer  is  in  the  database,  there  must  be  no  readers 
and  exactly  one  writer  in  the  database.  The  last  equation  in  each  object  discards  an  exiting  star 
operation  ad'ter  it  has  updated  the  counters  and  left  the  database  (nonstar  operations  are  already 
discarded  by  specification  equations).  This  allows  the  inv  equation  to  be  applied.  In  the  reductions, 
the  equation  allowing  the  invocation  to  pass  by  r«  is  applied  first,  then  the  invocation  is  discarded 
and  inv  is  expanded.  The  rest  is  jittering. 

5.7  Explicitly  Concurrent  Specification 

Admittedly,  star  operations  specify  concurrency  in  a  subtle  way.  A  more  conventional  approach, 
analogous  to  message  passing,  is  now  considered.  Unfortunately,  the  approach  relies  on  nontrivial 
modifications  to  OBJS’s  interpreter.  These  changes  define  a  new  language,  tentatively  named 
OBJC,  which  is  not  yet  implemented.  This  section  describes  the  proposed  modifications  and 
demonstrates  the  approach  on  the  Semaphore  and  Beaders/Writers  problems.  Verification  is  not 
discussed. 

We  begin  by  recognising  that  message  passing  can  be  simulated  by  other  language  constructs. 
Common  examples  that  provide  nonlocal  transfer  of  data  are  input /output  statements  and  global 
variables,  but  these  are  unavailable  in  OBJ3.  In  some  sense,  this  is  because  input  is  a  term  to 
reduce,  output  is  a  reduced  term,  and  only  local  variables  can  be  referenced.  In  fact,  OBJ3  enjoys 
a  simple  and  elegant  formal  semantics  partly  because  it  prohibits  global  constructs;  extending  the 
language  could  risk  these  nice  semantics.  But: 

This  world  of  systems  programming,  which  may  be  strongly  non>Church-Bosser  as  well 
as  nonterminating,  with  its  many  flags  and  strategies,  may  seem  like  Alice’s  Wonderland 
to  the  theorist,  and  he  might  well  long  for  a  return  to  the  simplicity  of  initial  algebra 
semantics.  However,  the  problems  posed  by  the  need  to  connect  with  the  real  world, 
including  input/output  and  real<time  programming,  are  not  going  to  go  away  [GKM87]. 

5.7.1  Message-Passing  Extensions 

Nevertheless,  the  extensions  are  confined  to  a  single  paxameterised  object,  KESSAGE,  providing 
message-passing  operations  and  sorts.  Of  course,  the  operations  cannot  be  realized  by  equations, 
they  must  be  treated  specially  by  the  interpreter.  Externally,  however,  MESSAGE  looks  like  a  user- 
defined  object. 

Figure  22  shows  the  parameterization  and  signature  of  MESSAGE.  Its  sorts  and  operations  allow 
disjoint  subterms  to  exchange  message  terms.  U  these  disjoint  subterms  are  thought  of  as  compu¬ 
tations  in  distinct  processes,  MESSAGE  operations  model  interprocess  communication.  The  theme  is 
simplicity.  Low-level  operations  are  provided  so  that  high-level  mechanisms  can  be  constructed. 

The  built-in  theory  TRIV  simply  requires  the  parameter  X  to  provide  a  sort  Elt.  Messages 
passed  by  an  instance  of  MESSAGE  are  of  this  sort. 

Several  new  sorts  are  provided  by  MESSAGE.  Message  insulates  a  user  from  the  nonlocal  be¬ 
havior  of  message-passing  operations.  All  MESSAGE  operations  have  this  coarity.  QIDL  provides 
alphanumeric  identifiers  that  are  used  as  symbolic  addresses  to  establish  the  connection  between 
communicating  subterms.  Massagold  is  just  Mat.  It  is  used  to  maintain  the  connection  between 
communicating  subterms  for  the  duration  of  a  transaction.  More  specifically,  when  a  message  is 
first  sent  to  a  sjrmbolic  address,  it  is  automatically  assigned  a  unique  identification  number.  A 
subsequent  reply  must  refer  to  the  original  message  by  its  number. 
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•kjact  mSSAOE  CX  : :  TEIf]  i* 

•art  !!••••(•  . 

•art  llaaaagalaa  . 
pratactiaf  4IDL  . 
kratactlag  lAT  . 
aakaart  nt  <  flaaaafa  . 
aakaart  Haaaacalas  <  lat  . 

ap  aaad  :  14  Kit  •>  Naaaafa  . 
ak  aaadiag  :  Id  Kit  ->  llaaaaga  . 
mp  aaat  :  MaaagalaB  •>  Haaaaga  . 
ap  wait  t  Haaaagalaa  •>  Haaaaga  . 
ag  aaltiag  «  Raaaagaiaa  ->  Haaaaga  . 
tf  aaltad  :  Haaaagalaa  lit  •>  Haaaaga  . 
ag  racaiva  >  Id  •>  Haaaaga  . 
ag  raeaiaiag  ;  Id  •>  Haaaaga  . 
ag  racaivad  :  Haaaagata  Dt  ->  Haaaaga  . 
ag  aagly  i  Haaaagalaa  Kit  ->  Haaaaga  . 
ag  aaglyiag  i  Haaaagafaa  Kit  ->  Haaaaga  . 
ag  ragllad  i  Haaaagaiaa  •>>  Haaaaga  . 


Figure  22:  Sig&Httue  of  MESSAGE. 

Notice  that  parameteruation  requires  the  operations  —  hence  messages  —  to  be  strongly 
sorted.  This  is  a  tradeoff.  Message  passing  is  more  convenient  with  polymorphic  operations,  but 
polymorphism  is  more  difficult  to  reconcile  with  OBJS’s  existing  semantics. 

When  discussing  a  transaction,  we  shall  call  the  subterm  initiating  the  exchange  the  “sender”; 
the  other  participating  subterm  is  the  “reeuver”.  Although  this  is  superficially  obvious,  notice  that 
the  receiver  sends,  and  the  sender  receives,  the  reply. 

5.7.2  Message-Passing  Protocol 

MESSAGE  allows  subterms  to  pass  messages  in  a  variety  of  ways.  To  illustrate  how  its  operations  are 
used,  however,  a  simple  synchronous  exchange  is  described  here.  A  sender  initiates  the  exchange 
by  constructing  a  message,  addresmg  it  with  an  identifier,  and  sending  it  to  a  recover.  When 
a  suitable  receiver  is  located,  a  message  number  is  generated  and  the  message  is  delivered.  The 
receiver  then  processes  the  message  while  the  sender  waits.  After  a  reply  is  constructed,  the  receiver 
completes  the  exchange  by  using  the  message  number  to  reply  to  the  sender.  Figure  23  pictorially 
describes  this  interaction  and  suggests  alternatives.  We  now  examine  this  simple  exchange  in  more 
detail. 

A  sender  sends  Iqr  applying  an  equation  that  introduces  a  Band  operation  into  its  subterm.  A 
send  takes  two  arguments:  an  entry  identifier  a  and  a  message  term  n.  If,  at  that  time,  there  exists 
a  subterm  receivingCe),  message  s  is  sent.  Otherwise,  sendCe.B)  reduces  to  sendingCe  ,b}  ,  thus 
mforming  the  sender  that  there  is  currently  no  receiver. 

A  receiver  receives  by  applying  an  equation  that  introduces  a  receive  operation  into  its 
subterm.  A  receive  takes  one  argument:  an  entry  identifier  e.  If,  at  that  time,  there  exists  a 
subterm  sending (e,B), message  ■  is  sent.  Otherwise,  recsive(e)  reduces  to  receivingCe),  thus 
infonning  the  receiver  that  there  is  currently  no  sender. 

The  protocol  is  designed  to  avoid  temporal  assumptions.  In  particular,  a  send  can  appear 
before  or  after  its  corresponding  receive.  The  first  operation  to  appear  blocks;  the  second  locates 
the  first.  In  addition,  the  protocol  is  nondeterministic.  If  multiple  matching  senders  or  receivers 
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replied (i) 


Figure  23:  Meuage-Pessing  Protocol. 
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Appear,  any  one  might  be  selected.  These  considerations  apply  to  the  vaic  and  reply  operations  as 
well.  In  fact,  the  vait/reply  snbprotocol  is  virtnally  identical  to  the  send/receive  subprotocol. 

Suppose  a  sendCe.a)  is  matched  with  some  receivingCe).  The  case  where  the  sender  is 
blocked  is  analogous.  Message  m  is  sent  itom  sender  to  receiver  by  assigning  a  message  number  i  to 
a,  reducing  sendCe.a)  to  sentCi),  and  reducing  raceivingCe)  to  receivedCi.a).  These  steps 
are  performed  without  any  intervening  reductions  (i.e.,  the  sequence  is  atomic). 

After  the  message  has  been  passed,  regular  reduction  resumes.  Since  the  sender  needs  to 
receive  a  reply,  it  retains  the  message  number  i  and  eventually  applies  an  equation  that  introduces 
aaitCi)  into  its  subterm.  Since  the  receiver  needs  to  send  a  reply,  it  retains  i,  constructs  a  reply 
r,  and  eventually  introduces  replyCi.r)  into  its  subterm. 

If  a  subterm  raplylngCi.r)  exists  when  «ait(i)  is  introduced  into  the  sender,  the  reply  r 
is  sent.  Otherwise,  «ait(i)  reduces  to  eaitlngCl),  thus  informing  the  sender  that  the  receiver  is 
not  currently  replying. 

If  a  subterm  vaitlngCi)  exists  when  reply(i.r)  is  introduced  into  the  receiver,  the  reply  r 
is  sent.  Otherwise,  repljCi.r)  reduces  to  replyingCi.r),  thus  informing  the  receiver  that  the 
sender  is  not  currently  waiting. 

Suppose  a  walt(i)  is  matched  with  some  replyingCi.r).  As  before,  the  case  where  the 
sender  is  blocked  is  analogous.  Reply  r  is  sent  from  receiver  to  sender  by  reducing  uaitCi)  to 
vaited(i.r)  and  replyingCi.r)  to  replied(i).  Again,  these  steps  are  performed  without  any 
intervening  reductions. 

Close  inspection  reveals  that  the  argument  i  of  both  waited  and  replied  is  unnecessary;  the 
message  number  can  be  retained  simply  by  copying  it.  This  brings  up  am  interesting  point;  »s  long 
as  both  sender  and  receiver  have  a  copy  of  the  message  number,  a  bidirectional  communication 
channel  exists  between  them.  Unfortunately,  the  channd  is  half>duplex;  the  sender  and  receiver 
must  alternate  in  their  roles  as  waiter  and  replier.  As  with  Unix  pipes  [Bac86],  however,  two 
half-duplex  channels  can  simulate  a  full-duplex  channel.  For  example,  the  second  message  sent 
from  sender  to  receiver  in  half-duplex  “mode”  can  be  a  unique  entry  identifier  constructed  from 
the  existing  channel’s  message  number.  The  sender  and  receiver  can  then  use  this  new  identiAer 
to  establish  another  half-duplex  channel  in  the  opposite  direction.  Of  course,  they  must  agree  on 
who  sends  on  which  channel. 

The  protocol  in  Figure  23  permits  both  synchronous  and  asynchronous  communication.  A 
synchronous  message  is  one  where  the  sender  waits  for  a  reply  and  the  receiver  sends  a  reply.  An 
asynchronous  message  is  one  where  the  sender  does  not  wait  for  a  reply  and  the  receiver  does  not 
send  a  reply.  Hybrid  methods  cause  problems.  For  example,  if  a  sender  behaves  asynchronously 
and  its  receiver  behaves  synchronously,  replying  never  reduces  to  replied  and  the  receiver  blocks 
forever.  At  first,  retry  counting  seems  like  a  solution  to  this  problem.  That  is,  the  receiver  can  re¬ 
peatedly  reduce  replying  to  reply  and  count  the  number  of  times  reply  is  reduced  to  a  replying. 
Unfortunately,  those  are  probably  the  only  reductions  occurring;  there  is  no  wray  to  tell  what  the 
sender  is  up  to.  Fortunatdy,  ignorable  replies  are  not  terribly  important;  a  sender  can  always 
eonununicate  its  desire  for  a  reply  as  part  of  the  message,  thus  instructing  the  receiver  to  behave 
accordingly. 

Notice  that  a  message  could  contain  MESSAGE  operations.  Although  the  idea  of  a  recursive 
“chain  letter”  is  intriguing,  we  avoid  defining  its  meaning,  at  least  until  a  reasonable  use  for  one  is 
discovered.  The  consequences  of  such  a  message  are  boggling. 

MESSAGE  provides  twelve  operations.  Earlier,  this  object  was  claimed  to  be  simple;  arguably, 
that  is  not  true.  But  if  we  try  to  reduce  the  number  of  operations,  the  object  becomes  more 
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Figure  24:  A  Client/Server  Term  with  a  Static  Number  of  Cheats. 

aataida<raeai*a(’aataida),aartrar('  ■  O.ellaataC 
ellaat('  ■  ■) , 
cliaatC*  *  •), 

cliaat(-  •  •>)) 


Figure  25:  A  Chent/Server  Term  with  a  Message  Catcher. 

difficult  to  use.  Perhaps  the  greatest  temptatioo  is  to  elimmate  sent  and  replied.  Instead  of 
reducing  to  these  monadic  operations,  we  could  simply  reduce  to  their  argument.  Unfortunately, 
this  compheates  the  detection  of  a  successful  send  or  receive  (resp.).  Likewise,  and  because  they 
bundle  together  their  two  arguments,  waited  and  received  are  necessary.  Another  temptation  is 
to  eliminate  sending,  waiting,  receiving,  and  replying.  Instead  of  reducing  to  these  blocked 
operations  after  a  first  attempt  to  communicate,  we  could  wait  until  both  the  sender  and  receiver 
are  ready  before  reducing  in  either.  But  these  operations  are  convenient,  both  for  specification  and 
interpretation.  A  specification  can  use  them  to  terminate  a  blocked  communication  attempt.  An 
interpreter  can  use  them  to  record  the  state  of  partiaUy  completed  communications;  no  internal  Ust 
of  blocked  operations  is  needed.  Clearly,  neither  send  nor  receive  can  be  eliminated.  Likewise, 
synchronous  communication  requires  wait  and  reply.  Finally,  consider  the  “geometry'*  of  the 
protocol.  Message-passing  solutions  are  often  unbalanced,  yet  these  twelve  operations  exhibit  a 
great  deal  of  symmetry.  A  simpler  object  would  lack  this  important  attribute. 

5.7.3  Centralized  Solutions 

A  concurrent  programming  problem  can  generally  be  solved  in  two  ways.  A  centralized  solution 
is  characterized  by  a  single  server  process  that  coordinates  the  execution  of  multiple  client  pro¬ 
cesses.  In  a  decentralized  solution,  the  responsibility  of  global  synchronization  is  shared  among  all 
processes.  OBJC  is  general  enough  to  specify  both  centralized  and  decentralized  solutions,  but  we 
shall  concentrate  on  centralized  solutions. 

A  client/server  solution  can  be  implemented  by  a  cheat  object  and  a  server  object.  A  term 
to  reduce  is  then  constructed  from  a  server  subterm  and  multiple  client  subterms.  Equations  in 
the  server  object  cause  reductions  in  the  server  subterm;  client-object  equations  reduce  elsewhere. 
Figure  24  shows  a  template  for  a  client/server  term  with  a  static  number  of  clients.  Operation 
outside  operates  as  before:  it  bundles  its  arguments  and  provides  context.  Unfortunately,  reducing 
such  a  term  to  a  result  is  also  as  awkward  as  before.  Figure  25  shows  a  template  that  uses  message 
passing  to  solve  the  problem.  With  this  term  structure,  the  server  or  any  client  can  send  a  message 
to  the  'outside  entry.  An  equation  like 

••t*iS«(rac«lv«4(I,S),S.C)  ■  S 

can  then  be  used  to  terminate  a  reduction  and  return  the  message  H  as  its  result.  This,  of  course, 
it  reminiscent  of  Lisp’s  catch/throw  mechanism.  Alternately,  outside  cam  be  thought  of  as  a 
“termination  server”.  If  the  number  of  clients  is  not  static,  a  dyadic  version  of  clients  can  be 
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Figure  26:  A  Client/Server  Term  for  an  Arbitrary  Number  of  Clients. 


used  to  maintain  a  list  of  clients.  Figure  26  shows  the  even  Lisp*ier  template. 

A  server  subterm  comprises  several  components.  At  minimum,  it  must  contain  the  message- 
entries  referenced  by  its  clients.  Synchronisation  and  scheduling  information  is  probably 
also  stored  there,  along  with  application*dependent  data. 

MESSAGE  guarantees  that  message-passing  reductions  at  the  server  interface  are  mutually  ex¬ 
clusive.  Conditional  synchronisation  and  mutually  exclusive  access  to  application-dependent  struc¬ 
tures  is  enforced  by  server  equations  that  maintain  counters  and  message  queues  within  the  server 
subteim.  Mutually  exclusive  access  to  the  counters  and  queues  is  guaranteed  by  the  atomicity 
of  equation  application  and  the  locality  of  server  state.  Scheduling  is  accomplished  by  reordering 
these  queues.  Notice  that  MESSAGE  exhibits  FCFS  behavior;  a  FCFS  scheduling  discipline  may  not 
require  explicit  queues. 

A  server  may  service  more  than  one  type  of  request  (e.g.,  allocate  requests  and  deallocate 
requests).  Such  a  server  may  receive  all  requests  through  a  single  entry  or  it  may  have  several 
entries  that  each  receive  requests  of  a  particular  type.  Bequests  are  segregated  by  using  different 
entry  identifiers.  A  single-entry  server  should  accept  requests  promptly,  whether  or  not  they  can 
be  serviced  immediately.  These  requests  should  then  be  queued  for  scheduling  (based  on  content) 
and  serviced  when  appropriate.  A  multi-entry  server  that  implements  a  FCFS  discipline  probably 
docs  not  need  scheduling  queues. 

A  dient  subterm  is  usually  simpler  than  the  server  subterm,  at  least  with  regard  to  message 
passing.  It  requests  service  with  a  send  and  obtains  results  with  a  vait. 

5.7.4  Exsmipies 

Figure  27  is  an  OBJC  server  object  that  models  the  behavior  of  a  FCFS  semaphore.  A  companion 
client  object  is  shown  in  Figure  28.  These  two  objects  are  somewhat  analogous  to  Figure  7,  where 
star  operations  are  used. 

The  server  object  in  Figure  27  begins  by  instantiating  MESSAGE  for  integer  messages.  As  before, 
operations  must  return  something,  so  p  and  v  return  the  semaphore’s  value.  Operation  nev  takes 
an  integer  argument  and  returns  a  semaphore  whose  counter  is  initialised  to  the  argument’s  value. 
A  scm^hore  is  bundled  by  a  esB  operation,  which  plays  the  role  of  aerver  in  Figure  25.  The  first 
two  arguments  of  sea  are  the  'p  and  'v  message  identifiers  (resp.)  —  the  server  entries.  The  last 
argument  of  sea  is  the  semaphore’s  counter.  Since  a  semaphore  is  a  FCFS  structure,  and  since  the 
multi-entry  approach  is  used  here,  explicit  queues  are  unnecessary.  Notice  that  a  blocked  reply  at 
one  entry  does  not  prevent  requests  at  the  other  entry  from  being  serviced. 

The  client  object  in  Figure  28  imports  the  server  object,  but  only  uses  its  operations  indirectly, 
via  messages.  It  also  instantiates  MESSAGE  again,  this  time  for  reduction-termination  purposes,  as 
in  Figure  25.  The  client’s  p  and  v  operations  are  equationaUy  translated  into  serm  requests. 
Since  the  server  provides  multiple  entries,  empty  messages  are  sufficient,  but  OBJC  requires  that 
something  be  sent.  In  CSP,  an  empty  messages  is  called  a  signAl  [Hoa78].  Operations  user  and 
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•bjaet  SDUPHOU  Is  sort  Ssaaphors  . 
prstsetiB(  IIT  ♦  IIESSSGE[IIT]  . 

op  BOO  :  Int  ->  SoBsphers  . 

op  SOB  :  Hssssgs  Nssssgo  Int  ->  SsBsphers  . 

sps  p  V  :  lat  •>  Int  . 

onr  I  :  lat  . 

oar  III  112  :  Hsssaga  . 

oar  I  ]  HossafsIsB  . 

aso  Croats  aa  laltialiaad  aaaapkors. 

04  aaad)  •  aaa(raetios(>p),raeaioa(*o),l)  . 

•••  Soroles  raqaaata. 

cq  saa<roeaload(l.lll).ll2,X)  ■  aaB(roply(l,p(X>>.in.pa)>  If  I  >  0  . 
aq  ss«(lll«racaioad(l,ll2),l)  ■  saa(lll.raply(l,o(I)),o(l))  . 

•••  Cat  raady  far  aara  raqaasts. 

aq  aaB(rapllad(I)  ,112,1)  ■  saa(raeslos(‘p),H2,l)  . 
aq  saa(lll,rapliad(l),I)  ■  aaa(lll,raeslos(>o),l)  . 

aq  p(I>  -  1  -  1  . 
aq  o(I)  B  1  o  1  , 

aado 


Figure  27;  A  Semaphore  Server  Object. 


abjaet  Old  is  aart  Osar  . 
protsetlag  SIMPIOU  . 
protat  :lBg  RtSSiaEClIT]  . 

sps  p  o  :  ->  Hsssaga  . 

op  aaar  >  lat  Hassaga  Hsssaga  ->  Osar  . 

op  Haas  i  Hassaga  •>  Osar  . 

op  oatsids  :  Hassaga  SaBaphsrs  Osar  Osar  •>  Hsssaga  . 

oar  H  Hi  H2  t  Hsssaga  . 
oar  1  li  12  >  HossagsItB  . 
oar  S  I  EaMpbora  . 

oar  01  02  1  Osar  . 
oar  I  I  Xat  . 

•as  Baqaost  saaaphars  saroies. 
aq  p  B  BaBd(>p,0>  . 
aq  o  B  aoad('o,0)  . 
aq  aaatd)  b  oait(l)  . 

•as  Badaea  to  tha  aaBbsr  of  tbs  aaar  that  fiaisbad  first. 

aq  asar(X.aBitod(ll,Hl),aaitad<l2,H2>))  b  doaa<soad(>aataido,X>)  . 
aq  aataido(roesiood(l,H),S.01,02)  b  h  . 


Figure  28:  A  Sexauphore  Cliexit  Object. 
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dona  play  the  role  of  clients  in  Figure  25.  Operation  user  bundles  a  user’s  two  requests  together 
with  a  “user  number”.  After  both  of  a  user's  requests  have  been  serviced,  its  user  number  is  sent 
to  'outside.  The  last  equation  reduces  a  term  to  the  user  number  of  the  hrst  user  to  finish.  As 
an  example, 

reduces  to  either  1  or  2. 

Notice  the  awkwardness  involved  in  ensuring  that  the  send  to  'outside  is  issued  only  after  a 
user’s  requests  have  been  serviced.  When  message  passing  is  used,  evaluation  strategies  cannot  be 
relied  upon  to  provide  sequencing. 

The  next  example  is  an  OBJC  solution  to  the  Eeaders/Writers  problem.  Again,  a  client/server 
structure  is  used  to  provide  mutual  exclusion  and  conditional  synchronization.  Figure  29  is  the 
server  object.  The  ^ent  object  is  shown  in  Figure  30.  These  two  objects  should  be  compared  to 
Figure  9. 

The  server  object  in  Figure  29  is  parameteiised;  as  before,  it  can  be  instantiated  with  various 
KEY  and  ITEM  objects.  Since  messages  are  database  items,  MESSAGE  is  instantiated  with  ITEM. 
Operation  rv  plays  the  role  of  server  in  Figure  25.  However,  it  behaves  quite  differently  than 
the  rv  of  Figure  9.  Specifically,  er  still  modifies  the  Database  argument  of  rv  in  place,  but  rd 
initiates  a  read  traversal  on  a  copy  of  the  database,  which  is  put  on  a  list  of  active  read  traversals, 
which  is  the  last  argument  of  rv.  This  technique  simplifies  the  read  traversal  algorithm.  Operation 
nev  creates  an  initialized  database;  the  two  conditional  equations  succinctly  provide  conditional 
synchronization  for  it.  A  database  contains  only  one  entry,  'rv.  Therefore,  a  request  message  must 
specify  whether  a  read  or  write  is  desired.  This  is  done  by  passing  a  rd  or  vx  subtenn,  which 
is  translated  into  a  get  or  put.  Operation  gate  is  used  like  Lisp’s  cone  to  construct  the  list  of 
active  read  traversals.  Notice  that  even  though  rv  has  only  one  entry,  the  FCFS  discipline  avoids 
an  explicit  queue. 

The  client  object  in  Figure  30  instantiates  a  Readers/Writers  database  that  maps  identifiers 
to  the  natural  numbers,  as  before.  The  client’s  read  and  vrita  operations  reduce  to  rd  and  vr 
server  requests  (resp.).  The  user,  done,  and  outside  operations  behave  almost  as  before.  A  user 
bundles  two  requests  together.  After  these  are  serviced,  the  user  reduces  to  done.  After  both  users 
are  done,  a  term  reduces  to  its  database  argument.  For  example, 

••«r<*rlta( ’frad.iOO) ,r««4( ’trad) ) , 

•sar(«rlta( *frad,300),arlta< ’f rad, 300) > ) 

reduces  to 

r«<racalaa(  ’n)  ,0,0,rae(  'trad,!  ,aad>  ,aar> 

where  x  is  either  100,  200,  or  300.  Notice  that  the  initially  intuitive 

a«talda(aaa, 

■sar<arlta(>rrad,100),arlta('rrad,raad('frad)  a  1)), 

••ar(erl«a(trad,aoo),«ri«a('frad,raad<'frad)  *  t))) 

is  not  only  nondeterministic,  but  it  contains  a  chain  letter,  as  discussed  previously.  In  order  to 
achieve  the  intended  effect,  explicit  sequencing  must  be  used.  The  trick  is  to  put  the  read  and 
write  operations  on  a  list  and  only  reduce  one  to  a  send  when  it  is  at  the  head  of  the  list.  After 
the  send  is  serviced,  it  could  be  removed  from  the  front  of  the  list  to  allow  the  next  operation  to 
be  processed. 

5.8  Verification  of  Implementations 

The  verification  techniques  of  Section  5.8  are  useful  for  proving  properties  of  a  particular  specifica¬ 
tion  or  solution.  In  this  section,  we  investigate  how  OBJ3  can  assist  in  the  top-down  development 


126 


•bjaet  UiDnS'tniTSliSClay  : :  KE1.  Itu  : :  ITEM]  is 
•erta  taadara-Hritara  Databaaa  • 
prataetiBf  IIT  «  HESSAGECITEK]  . 

op  aaa  :  ->  taadars-Hritars  . 

op  ra  :  Nasaaga  Int  lat  Databaaa  Naaaaga  ->  Kaadara-Hritara  . 

ap  rd  :  Kay  ->  Itoa  . 

op  ar  :  Kay  Itaa  ->  Xtaa  . 

op  gat  ;  Haaaagalaa  Kay  Databaaa  ->  Haaaaga  . 

ap  pat  :  Haaaagalaa  Kay  Itaai  Databaaa  ->  Databaaa  . 

ap  roe  :  Kay  Itaa  Databaaa  ->  Databaaa  . 

op  ood  :  •>  Databaaa  . 

op  aor  t  ->  Haaaaga  . 

ap  goto  :  Haaaaga  Haaaaga  ->  Haaaaga  . 

ap  patraply  i  Haaaaga  Databaaa  ->  Databaaa  . 

op  potdaaa  i  Databaaa  ->  Databaaa  . 

aar  H  K  i  Haaaaga  . 
bar  I  i  Haaaagala  . 
aar  D  :  Databaaa  . 
aar  X  tl  i  Roy  . 
aar  I  11  I  Itaa  . 

aar  IK  :  lat  .  aaa  aaobor  of  raadara 

aar  IK  :  lat  .  aaa  aaabar  of  arltara 

aaa  Croata  aa  laltialiaad  databaaa. 

aq  aaa  ■  ra(raeaiaa< *ra) ,0,0,aod,aor)  . 

•aa  laraica  raqaaata. 

eq  ra(raealaad(I,rd(K)) ,ll,n,D,X)  ■ 

ra(raeaiaa<*ra),tR  •  l,IH.D,gata(gat(l,K,D),K)> 

If  n  —  0  . 

eq  ra(raealaad(l,Br(K,l)).IK,n.D.K)  • 

ra(racaiaa('ia),fK,tV  a  l,pat(I,K.1.0) .R) 
if  <It  0)  aad  (IH  >•  0)  . 

•aa  Harga  aaraiead  raqaaata. 

aq  ra(H.IR.n.D.gata(rapliod(I).t))  •  ra(H.lt  •  l.n.D.I)  . 
aq  ra(H.n.n,patdaaa(D).I)  •  ra(H.IK.IH  -  l.D.R)  . 

•••  Road  traaoraal  algor Itba. 

aq  gat<I,K,aod>  ■  raplyd.aotfeaBd)  . 
aq  gat(f .K.roc(Xl,l,D))  ■ 
if  K  »  Kt  thaa 
roply(I,I) 

alaa 

gat(I.K.D) 

fi  . 

•a*  Hrita  traaoraal  algarltba. 

Figure  29:  A  Readers /Writen  Server  Object  (1  of  2). 


aq  pot(I.K,I,aad)  a  patraply(raply(g,I),rac<K,I,aod))  . 
aq  pot(I,XtXtroc(Xl.Xl.D))  ■ 

if  K  ■>  K1  tbaa 

patroply(raply(I.I)  .racd.l  ,D) ) 

alaa 

raedl.Il.pMd.K.I.D)) 

fl  . 

aq  p«traply(roplladd).D)  ■  patdoaod)  ■ 
aq  rae(Xl.Il.patdoaa(D>)  ■  patdoaa(raedl.ll,D})  . 


Figure  29:  A  Readers /Writers  Server  Object  (2  of  2). 
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•bjact  Osn  ia  aort  Uaar  . 

pratactiag  giDL  *  lAT  «  UADCU-nlTSUCgiDL.IAT]  . 

ap  rasd  :  Say  •>  Naaaaga  ■ 
ap  arlta  :  lay  Ztaa  •>  Naaaaga  . 
ap  aaar  :  Haaaaga  Haaaaga  ->  Uaar  . 
ap  daaa  :  ->  Uaar 

ap  aataida  :  Baadara-Hrltara  Uaar  Uaar  ->  Saadara'Hrltara  . 

aar  HI  H3  :  Haaaaga  . 
aar  I  ll  13  :  Haaaagalwi  . 
aar  HH  :  laadara-Hritara  . 
aar  B  i  Bay  . 
aar  I  i  Itaai  . 

aaa  Baqaaat  databaaa  aaraiea. 

an  raad(B)  ■  aaad<>ra.rd(B))  . 
aq  aritad.I)  ■  aaad(‘n,ar<B.l))  . 

aq  aaat(l)  ■  aalt(I)  . 

aaa  Badaea  ta  tha  flaal  databaaa  aalaa. 

aq  aaar(aaitad(Bl,Ht) .aaltad(B3.H3))  ■  daaa  . 
aq  aataida(Blt,daaa,daaa>  ■  BH  . 

aade 


Figure  30:  A  Readers/ Writers  Client  Object. 


of  a  solution. 

An  early  step  in  developing  an  object  is  to  coxistruct  a  specification  object.  A  specification 
object  implements  its  operations  autonomously;  it  does  not  employ  operations  from  other  user- 
de^ed  objects.^^  This  is  also  known  as  direct  implementation.  A  specification  object  is  more 
than  just  a  ‘thought  tool”.  Its  executability  allows  a  specification,  and  the  implementations  that 
import  it,  to  be  tested.  More  importantly,  properties  of  the  specification,  and  the  correctness 
of  the  implementations  that  import  it,  can  be  proven.  "Thus  a  true  top>down  implementation 
methodology  can  be  achieved”  [GHM78]. 

A  later  step  in  developing  an  object  is  to  construct  an  impiementation  object.  An  implemen¬ 
tation  object  implements  its  operations  via  operations  from  other  user-defined  objects.  Typically, 
this  is  done  to  reduce  time  or  space  requirements.  A  specification  object  may  have  multiple  imple¬ 
mentation  objects. 

Veriiying  such  a  development  means  proving  that  the  implementation  object  correctly  imple- 
ments  the  operations  specified  by  the  specification  object.  This  is  done  by  proving  that  for  each 
equation  in  the  specification  object,  the  equation  holds  when  its  operations  are  replaced  by  their 
implementations  from  the  implementation  object.  This,  in  turn,  can  be  done  by  showing  that  each 
specification  equation  reduces  to  true,  when  reduced  in  the  context  of  the  implementation  object. 

As  before,  however,  complications  arise  when  OB J3  is  used  as  a  theorem  prover.  In  particular, 
the  proof  tods  described  in  Section  5.8  are  also  needed  here.^*  The  proof  technique  is  demonstrated 
by  veriiying  the  correctness  of  an  implementation  step  in  the  development  of  a  symbd  table  main¬ 
tenance  program.  Both  the  methodology  and  sample  problem  are  taken  from  a  seminal  paper 
(GHMTS].  Aside  from  uring  OBJ3,  the  remainder  of  this  section  tries  to  fdlow  the  original  work 
as  closely  as  possible. 

'*Aa  object  ema  kszdly  ovoid  qaag  bailuia  operotioas. 

**AetBallr,  this  vexiileotioB  woe  dose  before  tbe  Reodeta /Writers  veiificotioa  —  oa  m  woxmap. 


128 


thaerj  IDSITlFin  !■ 

•ort  Identifier  . 
endth 

tkeery  iTTKIBVTE  ie 
sort  dttribate  . 
op  madefined  :  ->  Attribute  . 
endth 


Figure  31:  The  Requirements  for  Symbol  Table  Parameters. 


6.8.1  The  Symbol  Table  Problem 

A  good  example  of  a  problem  whose  solution  (i.e.,  whose  implementation)  must  be  both  time  and 
space  efficient  is  the  symbol  table  for  a  compiler  of  a  block'Structnred  programming  language,  the 
example  for  which  was  introduced  in  section  3.11  of  the  report.  This  section  considers  further 
det^  of  the  0BJ3  implmentaion  and  verfication  of  the  problem. 

The  problem  is  to  maintain  a  dynamic  mapping  from  program  identifiers  to  their  attributes. 
This  mapping  changes,  according  to  the  rules  of  static  scoping,  when  the  parser:  enters  a  program 
block,  encounters  a  variable  declaration,  and  exits  a  program  block.  A  symbol  table  provides  the 
following  operations. 

•  init:  Allocate  and  initialize  the  symbol  table  for  the  outermost  scope. 

•  enterblock:  Prepare  a  new  local  naming  scope. 

•  addid:  Add  an  identifier  and  its  attributes  to  the  symbol  table. 

•  leaveblock;  Discard  entries  from  the  most  current  scope  and  reestablish  the  next  outer  scope. 
If  already  in  the  outermost  scope,  do  nothing. 

•  isinblock:  Has  a  specified  identifier  already  been  declared  in  this  scope?  (Used  to  check  for 
duplicate  declarations.) 

•  retrieve:  Return  the  attributes  associated  with  the  most  local  definition  of  a  specified  identi¬ 
fier. 

5.8.2  Specification  of  the  Symbol  Table 

For  a  symbol  table  to  map  abstract  identifiers  to  abstract  attributes,  its  object  must  be  parameter- 
ised.  The  parameters  are  required  to  satisfy  the  IDENTIFIER  and  ATTRIBUTE  theories  in  Figure  31. 

Specification  of  the  required  operations  is  straightforward;  the  specification  object  is  shown 
in  Figure  32.  In  order  to  test  the  specification,  it  must  be  instantiated.  Figure  33  instantiates  a 
STMBOLTABLE  that  maps  strings  to  the  natural  numbers;  some  example  reductions  are  also  shown . 

5.8.S  Implementation  of  the  Symbol  Ikble 

A  symbol  table  is  implemented  as  a  stack  of  mappings.  As  promised,  the  STACK  and  NAPPING 
objects  do  not  need  to  be  implemented,  the  direct  implementations  provided  by  their  specification 
objects  are  sufficient.  Both  objects  are  parameterized.  STACK  takes  one  parameter,  characterized  by 
the  ELEMENT  theory  in  Figure  34.  MAPPING  takes  two  parameters,  characterized  by  the  DChAIN  and 


129 


•kj«et  STIlBIILTAlUri  < :  ISSnirin.  A  : :  ATTUBOn]  ia 
a«rt  Syabaltabla  . 

f  talt  t  •>  •iBbaltabla  . 

•p  aatarhlack  <  Sy«balt«bla  ->  Syabaltabla  . 

•f  aiMld  <  Aytaltabla  Maatlfiar  Attrlbata  ->  Syabaltabla  . 

iMvablack  <  Sybaltabla  ->  Sybaltabla  . 

•p  Isiablack  1  Syabaltabla  Maatlfiar  '•>  Baal  . 
wf  rattiava  i  Sybaltabla  Idaatifiar  •>  Attrlbata  . 

aar  S  :  Sybaltabla  . 
aar  I  11  :  Idaatifiar  . 
aar  A  i  Attrlbata  . 

aq  laaaabloekdait)  ■  lait  . 

aq  laaaablaek(aatarblock<S) )  ■  S  . 

aq  laaaabloek(addid(S,I,A))  ■  laaaablaek(S)  . 

aq  laiabla«k<iait,l)  ■  falaa  . 
aq  iaiablack<aatarblack<S) ,1)  ■  <alaa  . 
aq  iaUblack<addid<S.I.A>.Xl)  ■ 
if  t  ■>  II  tbaa 
traa 

alaa 

laiablack<S,ll> 

fi  . 

aq  ratrlaaa<iait,I)  a  aadaflaad  . 
aq  ratriaaa(aatarblaek(S),X)  a  ratriaaa(S,l)  . 
aq  ratriaaa(addid(S,Z,A),It)  a 
if  1  aa  II  tbaa 
A 

alaa 

ratrlaaa(S,It) 

fi  . 

aada 


Figore  32:  The  Symbol  TbUc  Spediication  Object 


IDOTirm-TO-qiD  tram  IDDITIFIU  to  QID  ia 
aart  l^aatifiar  to  Id  . 
aada 

vloa  ATTIIBUTC-TO-UT  trom  iTTlIBUTE  to  BAT  ia 
aart  Attribata  to  Bat  . 
op  aadafiaad  to  0  . 

aadtr 

■aka  ST  ia  STIIBOLTAlUtlDEITIFIIB-TD>QlD,ATni^|IE^-B(MI&glMa. 


radaca  la  ST  :  ratriaaa(aatarbloek(addid<addid<iBit,'bad.3).'ad,6)>, 
•bad) 

raarltaa:  T 
raaalt  lalati  3 


radaca  ia  ST  i  ratriaaa<aatarblack<addid<addid(iait,*bad,3),>ad,C)>, 
•bill) 

raaritaa:  B 

raaalt  Sara:  0 


radaca  ia  ST  ■  iaiablack(aatarblaek(addid(addid(iait.>bad,S>.*ad.e>). 
•bad) 

raaritaa:  i 
raaalt  Baal:  falaa 


radaca  ia  ST  :  iaiabloek(loa«ablock(aatarblack<addid(addid(iait, ’bad, 
3),^ad.«))).>bad) 
raaritaa:  7 
raaalt  Baal:  traa 


radaca  la  ST  :  iaiablaek(laa*abloek(aatarblaek(addid(addid(iait,^bad, 
3),*ad.6))),*bill) 


raaritaa:  • 
raaalt  Baal:  falaa 


(b):  Rednetiona. 


Figure  33:  Instantiating  and  Testing  a  Symbol  Table  Specification. 


thaary  BLUISIT  la 
■art  nasaat  . 
ap  aadafiaad  :  >>  Elaaaat  . 
aadth 


Figure  34:  The  Requirements  for  Stack  Parameters. 


thaary  DOBAII  ia 

■art  Baa  ala  . 
aadth 

thaary  aABdt  ia 
■art  Baafa  . 

ap  aadafiaad  i  ->  Baaga  . 
aadth 


Figure  35:  The  Requirements  for  Mapping  Parameters. 
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•bjact  STACIU  :t  CLOUIT]  is 
•ort  Stack  . 

ap  aaaataek  :  ->  Stack  . 

ap  paah  :  Stack  tlaaaat  ->  Stack  . 

ap  pap  :  Stack  ->  Stack  . 

ep  tap  :  Stack  ->  Elaaaat  . 

ap  lamaa  ;  Stack  ->  Baal  . 

ap  raplaca  ;  Stack  SlaMat  ->  Stack  . 

aar  8  :  Stack  . 
aar  I  i  Blasaat  . 

aq  pap(Baaatack)  >  aaaataek  . 

aq  pap(pB8h(8,I)>  ■  S  . 

aq  tap<aaastaek)  ■  aadafiaad  . 
aq  tap(pB8h(S,B)>  ■  I  . 

aq  iaaaaiBaastaek)  a  tna  . 
aq  laaaa(pBah<S,l))  ■  Salaa  . 

aq  raplaea(S>B)  ■  paak<pap<S) ,1)  . 

aa4a 


Figure  36:  The  Stack  Specification  Object. 


RANGE  theories  in  Figure  35.  The  STACK  and  NAPPING  specification  objects  are  shown  in  Figure  36 
and  Figure  37  (resp.). 

A  SYMBOLTABLE  implementation  object  is  shown  in  Figure  38.  There  are  only  two  “high¬ 
lights”.  First,  notice  the  overwhelming  ugliness  of  the  importation  of  a  stack  of  mappings.  As  the 
comment  indicates,  parameterized  views  would  be  a  big  improvement.^*  Second,  consider  the  new 
operation  synt.  This  is  a  representation  operation.  Like  a  type-breaking  function  in  Modulas,  a 
representation  operation  allows  something  of  one  sort  to  be  treated  as  if  it  is  of  another  sort,  but 
no  conversion  or  coercion  takes  place.  For  example,  in  the  equation 

lalt  ■  •rBt(pBah(Ba««taek,Mnap>) 

from  Figure  38,  synt  is  used  to  treat  a  nearly  new  stack  as  an  empty  symbol  table.  Snbsorting 
could  obviate  representation  operations  in  many  cases,  but  circular  snbsort  relations  might  arise  in 
others. 

Since  the  implementation  object  has  not  yet  been  verified,  it  should  be  tested.  Figure  39  is 
analogous  to  Figure  33,  it  instantiates  a  SYMBOLTABLE  mapping  strings  to  numbers  and  shows  some 
example  reductions.  Clearly,  the  rewrite  count  is  an  inappropriate  measure  of  an  implementation’s 
efficiency. 

5.8.4  Verification  of  the  SymboLThble  Implementation 

As  before,  there  are  several  important  steps  in  the  verification.  First,  a  proof  object  is  constructed 
from  the  implementation  object  in  Figure  38.  This  proof  object  is  then  instantiated  and  augmented 
with  any  necessary  lemmas.**  Equations  from  the  specification  object  are  then  reduced  in  the 
context  of  this  augmented  object.  Finally,  of  course,  the  lemmas  are  proven. 

Although  a  correct  implementation  must  implement  every  operation  in  a  specification,  we 
consider  only  a  single  equation  from  the  specification  object.  This  equation  is  an  interesting  one; 

**TheK  aie  Uata  tAst  pBnmetensed  new*  miakt  b«  nppoitad  ia  a  Utet  vetnoa  at  the  iaterpretci  [GW88]. 

‘*ABtomatie  theorem  proeiag  is  aa  iterative  ezeroM;  ea^  aasaccesafU  itexatioa  saggests  aew  lemmas. 
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object  IIAPPIIG[0  ::  DORAII,  K  ::  UlOEj  io 
■ert  Rapping  . 

op  nanap  :  ~>  Rapping  . 

op  dofaap  :  Rapping  Doaain  Ranga  ->  Rapping  . 
op  avsap  :  Rapping  Doaaia  ->  tango  . 
op  iadafinad  :  Rapping  Oanain  ->  Baal  . 

var  R  :  Rapping  . 
var  0  Di  :  Oaaaia  . 

var  t  :  tango  . 

aq  ovBap(aanMp.D)  ■  andafiaad  . 
oq  avBap(dafB^(R,0,t),01)  ■ 
if  D  ■>  01  than 
t 

aiaa 

ovaap(H,Dl) 

fl  . 

aq  lsdaflBad(BaiBap,Di>  ■  falaa  . 
oq  lsdafiBad(daflBap(H,D,t)  .01)  ■ 

If  0  ■-  01  than 

traa 

alaa 

isdafiaad(H.Ol) 

fi  . 

OBdO 


Figure  37:  The  Mapping  Specification  Object. 


in  particular,  it  it  recursive  and  its  proof  requires  a  lemma. 

A  proof  object  is  constructed  exactly  as  before.  Conditional  equations  are  transformed  into 
regular  equations,  variable  operations  replace  variables,  the  symbolic  equality  operation  replaces 
and  the  eager  conditional  operation  replaces  if_thon_el8e.fi.  Recall  that  these  proof  tools 
are  provided  by  PROOF-TRUTH.  Figure  40  shows  the  proof  object  corresponding  to  the  implementa¬ 
tion  object  in  Figure  38. 

Unfortunately,  implementation  via  importation  causes  a  subtle  problem.  It  is  not  difficult 
to  solve,  just  inconvenient.  Namely,  a  specification  object  imported  by  an  implementation  object 
must  also  be  transformed  into  a  proof  object;  the  proof  object  is  imported  instead.  Transformation 
stops  at  this  second  level  because  —  by  definition  —  a  specification  object  does  not  import  other 
user-defined  objects.  The  STACK  and  KAPPING  proof  objects  are  not  shown  here. 

The  next  step  is  to  construct  a  verification  condition.  We  want  to  verify  that  the  equation 

rBtrisvB(addld(S,I,S) ,11)  ■ 
if  I  —  XI  tk«B 
t 

•iBB 

rBtrl«VB(S,Il) 

fl 

from  Figure  32  holds  in  the  context  of  Figure  40.  The  ■  is  a  metasymbol,  not  a  built-in  operation.  In 
order  to  make  the  equation  reducible,  it  is  replaced  by  as*.  Variable  operatioiu,  the  representation 
operation,  and  PROOF-TRUTH  operatioiu  traxuform  the  equation  into  the  verification  condition  shown 
in  Figure  41. 

Object  retrieve  in  Figure  41  instantiates  the  proof  object  from  Figure  40  and  augments  it  with 
a  lemma  that  was  discovered  to  be  necessary  in  an  earlier  proof  attempt.  Following  that,  recursion 
is  limited  to  avoid  an  infinite  reduction  and  the  verification  condition  is  reduced.  Examination  of 
the  detailed  OBJ3  reduction  trace  demonstrates  that  the  proof  proceeds  essentially  as  it  does  in 
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•bjaet  STnOLTAaUCi  : :  IDCRirin.  A  : :  ATTllBCTC]  ia 
••rt  S^rabaltabla  . 

•p  Ibit  t  ->  Syaboltkbl*  . 

•p  ntarblock  :  Syaboltabl*  ">  Spaboltabl*  • 

op  addld  :  Sya^Atabl*  Idaatifiar  Attribata  ->  Syaboltabla  . 

ap  laavablack  :  Spabaltabla  ->  Syabaltabla  . 

ap  iaiablaek  :  Syabaltabla  Idaatlfiar  ->  Baal  . 

ap  ratrlava  :  Syabaltabla  Idaatlfiar  ->  Attribata  . 

aaa  prataetiaf  STACIC 

aaa  ILBIIIIT-TO-IIAPPiaOOMlUIl-TO'IDBRXnn.BABaS-TO-ArTUBOTE]]  . 

prataetii^  STACB 

(aiaa  ta  MmiO 
talas  ta  1  la 

sart  Baaaia  ta  Idaatlfiar  . 
aads, 

alas  ta  A  is 

sart  Saaga  ta  Attribata  . 
ap  aadafiaad  ta  aadafiaad  . 
aada] 

la 

aart  Klaaaat  ta  Rappiag  . 

ap  aadafiaad  ta  aaaaap  . 
aada]  . 

ap  syat  :  Stack  ->  Syabaltabla  . 

aar  S  i  Stack  . 
aar  I  :  Idaatlfiar  . 
aar  A  :  Attribata  . 

aq  lalt  ■  syBt(pasb(aaastack,aasBap>)  . 

aq  aatarblack<syBt<S))  a  syat<paab<S.aisaap))  . 

aq  addld(tyat(8),I,A)  ■  syat(raplaca<S.dafBap(tap(S).I,A)))  . 

aq  laaaablacb(ayBt(S)}  a 
if  iaaas<pap(S)>  tbaa 

ayBt<raplaca(S,aanap)  ) 

alsa 

syBt(pap(S}) 

fl  . 

aq  islablack<syBt(S),I)  a  isdafiaad(tep(S>,I)  . 

aq  ratriaaa<syBt(S)>I)  a 
If  IsaasiS)  tbaa 

Figure  38:  The  Symbol  Table  Implementation  Object  (1  of  2). 


aadafiaad 

alsa 

If  lsdaflaad(tap(S).X>  tbaa 
asBap(tsp(8).I) 
alsa 

ratrlasa(syBt(pap(S)) ,1) 
fl 

fl  . 


Figure  38:  The  Symbol  Table  Implementation  Object  (2  of  2). 
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vi««  lOnririll-TO-lIZO  froa  IDOTirint  t«  qio  is 
••rt  Idaatiflsr  to  Id  . 

OltdT 

vioo  imtwm-n-wtt  froa  kmivrrt  to  ur  to 
sort  dttrlboto  to  lot  . 
op  oadof iood  to  0  . 
oadv 

aoko  ST  lo  STIIMLTABLS[IOBRina-TO-qiD.lTni^|(II|;-Brf||llft«HMa. 


rodoeo  la  ST  :  ratrls*a<aBtarblock(oddld(oddld(lBlt,>bad,3),'ad,S)>, 
'bad) 

roorltos;  3S 
rosBlt  Salat:  3 


rodaeo  la  ST  :  ratrio*a<oBtarbloek<addid(addid(lalt, 'bad,3>, *ad>6)), 
•bill) 

roorltoo:  33 
roaalt  Zoro:  0 


rodaeo  ia  ST  t  iaiablaek(aatarbleek(addid(addid(iait, •bad,3>>*ad,6>> , 
•bod) 

roorltoo:  13 
rooalt  Bool:  faloo 


rodaeo  ia  ST  :  lsiBbleek(laaoableek(aBtarblock(addid(addid<ialt, •bod, 
3).^od,6))),'bBd) 
rooritos:  33 
roaalt  Bool:  trao 


rodaeo  ia  ST  :  iaiabloek(loaoabloek(oatorbloek(addid<addid<lalt, 'bad, 
3),'od,«))),'blll) 


raoritao:  34 
roaalt  Bool:  faloo 


(b):  RedactioBs. 


Figure  39:  Instantiating  and  Testing  a  Symbol  Ibble  Implementation. 


I 
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•bjaet  STnOLTABUa  ISEITirxn.  i  ;;  ATTlIMrn]  is 
ssrt  Syabsltsbls  . 

sp  ialt  s  ->  tfabsltsbls  . 

sp  satsrblsek  i  Syaboltsbls  •>  Syaboltsbls  . 

sp  s4did  I  SjBboltsbls  IdsBtlflsr  Attrlbsts  ->  Sybsltsbls  . 

sp  Issvsblsek  I  SyBbsltsbls  ■*>  Spabsltsbls  . 

sp  isiablsck  :  Spaboltsbls  Idsatiflsr  ->  Isol  . 

sp  rstrisss  i  Spsbsltsbls  Idsstifisr  ->  Attrlbsts  . 

•••  prstsctlsf  STACIt 

SSS  IUIIDT-rO-IIAfV»0CMilUIf*n-lMirimt,IAMI-lD-ATTUaaTI]]  . 

prstsetiac  STACI 
Cviss  ts  HAmH 
Cvlss  ts  1  is 

ssrt  Dfsis  ts  Idsatiflsr  . 
sadv, 

visa  ts  A  is 

ssrt  laags  to  Attrlbsts  . 
sp  sadsf iasd  ts  sadsfisod  . 
sad«] 

is 

ssrt  tlsMSt  ts  Happisg  . 

sp  sadsf  iasd  ts  asnsp  . 
sads]  . 

sp  spat  ]  Stack  •>  SpabsltsbXs  . 

prstsetiac  lAT  . 

op  sear  :  lot  ->  Stack  . 
sp  itar  I  Sat  •>  Idsatiflsr  . 
op  star  :  Sat  ->  Attrlbsts  . 

protsctiag  nOOF'TIOTICSpBbsItabls]  . 
prstsetiac  naor>TmiCStaek]  . 
prstsetiac  raoor-TWmCldsatifisr]  . 
prstsetiac  PUar-TIuniCAttribats]  . 

aor  S  I  Stack  . 
aar  I  i  Idsatiflsr  . 
aar  A  >  Attrlbsts  . 

sq  lait  ■  spt<pask<asastack,asatp))  . 

oq  satarklock<siM(S))  ■  spat<paak<S,aiaaap))  . 

sq  addld(s}Bt(S>,I,A)  m  spat(roplaes(S.dsftaap(tsp<S).I,A>)>  . 


Figure  40:  The  Symbol  Table  Proof  Object  (1  of  2). 
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•q  l«avablock(syBt(S))  ■ 

•if  iaB*«(pep(S))  than 

■yat  (r*pl>c*(S  .■■••■•p) ) 

•la* 

ayBt(pop(S) ) 

fi  . 

•q  iaiBbleck(ayBt(S) ,1)  ■  iad*fiBad(tap(S),I>  . 

•q  r*tri***(ayat(S) ,1)  ■ 

•if  iaB*a(S)  th*a 
■adafiaad 

•la* 

•if  iad*fia*d(tap(S) ,1)  tkaa 
••■Bp(top(S),l> 

•la* 

ratriav*  (ajiBt  (pap(S)  ) ,  1 ) 
fi 

fi  . 

•ado 


Figure  40:  The  Symbol  Table  Proof  Object  (2  of  2). 


•bjaet  umisn:  ia 

•ataadiag  STiaaLTABLE[IDEITlFin-TO-qiD.imiBOTE-TO>MT]  . 
var  S  :  Stack  . 

•q  iaa*a(S>  ■  fala*  . 

•ado 


•T  (r*earai*a~liaiit  :sbj  "STnOLTABLE"  sop  ’■r*tri*v*~  sliait  1) 
radac* 

r*trl*T*(addid(ayBt(a*ar(0)),iTar<0),a*ar(0)),ivar(l)> 

■•■ 

•if  laar(O)  ■•■  ivar(l)  thaa 
••ar(0) 

•la* 

ratriovaiapat (avar (0) ) , lvar( 1 > ) 

fi  . 


••  (racaraioa-liait  s»bj  “STMOLTABU"  (l^.  •teMUiRttCba  wd  Redactioa. 

rodae*  ia  UnilTI  :  ratri*v*(addid(ayat<aaar<0)),iaar(0),aTar(0>)» 
lvar(l)>  aif  iaar(O)  i*ar(i)  thoa  avariO)  •!••  r«tri*v*( 
•yBt(aTar(0)),ivar(l))  fi 
raaritoas  iS 

raaalt  •*•!:  tra*  ...  _ 

(b):  Rcsvlt. 


Figure  41:  Correctness  Proof  of  retrieve  Implementation. 
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•kjMt  imim  is 

•st«a4lBg  tTliMLTUU[IOaTiria-TO-qtD.iTttlKm-TO-lfcTl  . 

fi  !  SfBkaltskl*  ->  Baal  . 

Miag  PBOOr-CiSB  •  (aart  Sart  ta  Syabaltabla,  ap  p  ta  pl>  . 
aar  t  i  Stack  . 

aq  pi(syBt(S))  ■  isaaa(S)  aaa  falsa  . 

aade 

radsea  pi(iait)  . 

abjact  ■BTkXBVXl  is  astsadiag  UTIIIVE  . 

aq  isaa«<saaT<0) )  •  falsa  . 
aada 


radaca  pi(aBtarblaek(spBt(aTar(0)))>  . 

radaea  pi(addid(spBC<aTar(0)>ii«ar<0),aaar(0))>  . 

tadaes  pl(laaaablaek(spm<saas<0))))  .  (a);  and  Rednetions. 


radaca  ia  llTBIlfB  >  pi(iait) 
raaritaai  4 
rasalt  laali  traa 


radaea  la  linimi  :  pi(aatarblaek(syBt(aaar(0>))) 

raarltas:  4 
rasalt  Baali  traa 


radaea  ia  UTUmi  t  pi(addid(syat<s«ar(0)),i«ar(0),a*ar(0))> 
raarltas:  S 
rasalt  Saali  traa 


radaea  ia  UniKni  :  pl<laaaablsek<sjnt(Baar<0)))) 


raarltas:  10 

rasalt  Saal;  traa  (b):  ResnlU. 


Figure  42:  Proof  of  Lexnxu  for  retrieve  Proof. 


the  original  work. 

The  final  step  is  to  prove  the  lemma  assumed  in  Figure  41.  For  proof,  the  lemma  is  formulated 
as  part  of  an  equation  for  a  predicate  on  symbol  tables.  If  the  predicate  can  be  proven  invariant  — 
that  is,  if  it  is  true  for  all  symbol  tables  —  then  the  lemma  is  true.  Invariance  is  proven  as  before: 
by  structural  induction. 

Figure  42  shows  the  proof.  Once  again,  the  proof  object  from  Figure  40  is  instantiated.  This 
time,  however,  it  is  augmented  with  the  predicate  operation  pi  and  the  case-analysis  rule  from 
PROOF-CASE.  The  first  reduction  is  the  basis;  it  shows  that  the  predicate  is  true  for  an  initial¬ 
ised  symbol  table.  Object  RETRIEVEI  is  the  inductive  hypothesis;  it  augments  RETRIEVE  with  an 
equation  that  makes  the  predicate  true  for  symbol  tables  constructed  firom  one  fewer  operation 
invocation  than  those  considered  in  the  inductive  steps.  The  last  three  reduction  are  inductive 
steps;  they  show  that  the  predicate  holds  for  S3rmbol  tables  constructed  from  one  more  operation 
invocation  than  those  assumed  in  the  inductive  hypothesis. 

In  general,  an  inductive  hypothesis  is  necessary  for  structural  induction.  For  this  proof,  how¬ 
ever,  the  equation  added  in  RETRIEVEI  ia  never  used;  the  equations  from  RETRIEVE  are  sufficient  to 
prove  the  inductive  steps.  Incidentally,  only  the  leaveblock  proof  requires  the  case-analysis  rule. 

5.9  Conclusions  and  Future  Work 

Although  an  equational  language  is  not  typically  used  to  record  design  decisions  regarding  concur¬ 
rency,  our  work  demonstrates  that  concurrent  behavior  can  be  specified  equationally.  Star  opera- 


138 


tions  can  specify  the  allowable  interaction  of  processes  that  are  competing  for  some  shared  resource 
and  message-passing  operations  can  model  interprocess  communication.  An  equational  language 
is  also  a  useful  tool  for  reasoning  about  an  equational  specification.  In  particular,  properties  of 
a  specification  can  be  verified  and  development  steps  can  be  proven  correct.  Actually,  verifying 
a  development  step  can  be  viewed  as  verifying  a  set  of  properties;  however,  the  two  activities  are 
pragmatically  distinct. 

OBJ3  is  a  good  language  for  this  research.  It  has  powerful  parameterization  mechanisms 
and  a  flexible  type  system.  Subsorting  and  overloading  is  especially  convenient.  In  addition,  it  is 
available,  well  documented,  and  appears  to  be  readily  modifiable.  This  last  characteristic  is  only 
partially  confirmed. 

The  work  described  here  is  experimental  and  preliminary.  In  fact,  equational  specification  and 
verification  is  only  one  facet  of  an  envisioned  development  methodology  for  concurrent  software. 
This  is  a  two-tiered  methodology  (cf.  Larch  [Win'S?]),  where  equationally  defined  operations  are 
used  as  auxiliary  functions  in  an  axiomatic  specification  of  a  concurrent  program.  The  implemen¬ 
tation  tier  is  supported  by  a  conventional  concurrent  programming  language  (e.g.,  SR  [AOC*88]). 

There  is  much  more  work  to  be  done.  The  following  proposals  are  in  suggested  chronological 
order. 

As  with  any  methodology,  experience  with  more  and  larger  examples  is  necessary  to  determine 
if  it  is  general  enough  to  be  useful.  There  are  several  traditional  benchmarks  that  seem  suitable: 
the  Dining  Philosophers  problem,  the  Sleeping  Barber  problem,  and  some  variety  of  electronic-mail 
system.  Each  problem  should  require  about  one  man-week  to  specify.  Property  verification  tends 
to  be  more  time  consuming;  however,  two  man-weeks  per  problem  should  be  sufilcient  for  small 
sets  of  fundamental  properties. 

The  task  of  constructing  a  proof  object  should  be  substantially  simplified  —  or  even  eliminated 
—  thereby  obviating  the  proof  tools  in  Appendix  5.10.  One  way  to  accomplish  this  is  to  modify 
OBJ3  to  reduce  terms  containing  variables  (cf.  Apfiru  [TE81]).  An  estimate  of  the  time  required 
for  this  ambitious  project  should  be  deferred  until  the  original  developers  are  consulted.  A  less- 
ambitious  modification  is  to  overload  the  built-in  operations  so  that  they  evaluate  their  arguments 
normally,  symbolically,  or  eagerly  depending  upon  the  presence  of  variable  operations.  Such  a 
project  might  require  two  or  three  man-months.  Alternatively,  a  group  of  objects  that  implement  a 
unification  algorithm  is  available  [GW88].  These  should  be  evaluated  for  suitability  as  proof  tools. 

The  semantics  of  conditional  equations  should  be  defined  equationally,  so  that  they  can  be 
reduced  directly  rather  than  requiring  a  transformation  to  regular  equations.  This  should  be  easy. 

The  MESSAGE  protocol  should  be  shown  to  be  general  enough  to  model  the  message-passing 
protocols  of  currently  available  concurrent  programming  languages.  In  particular,  the  flexibility  of 
SR’s  mechanisms  should  be  captured. 

Finally,  the  mathematical  semantics  of  the  message-passing  operations,  as  well  as  their  im¬ 
pact  on  the  verification  methodology,  should  be  investigated.  In  addition,  these  operations  should 
be  implemented,  by  modifying  the  OBJ3  interpreter,  thus  constructing  an  interpreter  for  OBJC. 
One  approach  to  mathematically  specifying  the  semantics  is  that  used  in  the  de^tion  of  FOOPS 
[GM86b],  an  equational  language  supporting  states  (i.e.,  program  variables).  Namely,  an  OBJ3  in¬ 
terpreter  could  be  implemented  in  OBJ3,  then  modified  to  support  message  passing.  The  semantics 
of  OBJC  would,  therefore,  be  defined  in  terms  of  the  semantics  of  OBJ3.  A  more  straightforward 
definition  —  if  attainable  —  would  be  desirable;  the  topic  should  be  studied  for  one  or  two  man- 
months.  An  OBJC  implementation  should  require  about  three  or  four  man-months. 
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5.10  Proof  Tools 

•bjact  raoor-MML  i« 

pratactlmg  TIVTI-fALUE  . 
protect  iag  MOL  . 

op  olf.thoa_olflo.fi  :  lool  Bool  Bool  ->  Bool 
[fltratogy  (13  3  0)  (othor  (B  B  B)  proc  0]  . 
op  .oflo.  t  Bool  Bool  ->  Bool  [fltratagr  (1  3  0)  proc  Si]  . 

var  B  T  B  :  Bool  . 

oq  oif  trao  thoa  T  olao  I  f 1  ■  T  . 
oq  olf  falao  thoa  T  olao  E  fi  ■  B  . 
oq  olf  B  thoa  trao  olao  trao  fl  ■  trao  . 
oq  olf  B  thoa  falao  olao  falao  fi  >  falao  . 

oar  Bt  B3  I  Bool  . 

oq  B  000  B  ■  trao  . 

•••  logical  aabatltatloa 

oq  olf  B  thoa  B  oflo  B1  olao  B3  fl  ■ 
olf  B  thoa  trao  ofl*  B1  olao  B3  fi  . 

oq  olf  B  thoa  B1  >flo  B  olao  B3  fl  ■ 
olf  B  thoa  B1  oflo  trao  olao  B3  fl  . 

oq  olf  B  thoa  B1  olao  B  ofl*  B3  fl  ■ 
olf  B  thoa  B1  olao  falao  oao  B3  fi  . 

oq  olf  B  thoa  B1  olao  B3  oa*  B  fi  ■ 
olf  B  thoa  B1  olao  B3  oo*  falao  fl  . 

ooo  aoto  logical  aahotltatloa 

oar  BBCOBrOllJEL:  Bool  . 

oq  oif  i  thoa  (B  or  A)  oflo  trao  olao  C  fl  > 
olf  A  thoa  (B  or  trao)  >00  trao  olao  C  f 1  . 

oq  olf  A  thoa  (B  oad  A)  oo*  trao  olao  C  f 1  ■ 
olf  A  thoa  <B  aad  trao)  oao  trao  olao  C  f 1  . 

oq  oif  A  aa4  B  thoa  <C  aad  (A  or  D>)  ooo  trao  olao  B  f 1  o 

olf  A  aad  B  thoa  (C  oad  (trao  or  D>>  oao  trao  olao  B  fi 

oq  olf  A  aad  B  thoa  <C  or  B)  oao  trao  alao  D  f 1  o 

oif  A  aad  B  thoa  (C  or  trao)  oao  trao  olao  D  fl  . 


ohjoet  PBOOr-TBUna  I :  TBIT]  la 
protactlag  TBVIB-TAUIB  . 
protoctii^  nOOr-BOOL  . 

op  atf_thaa.alao_fl  1  Bool  Bit  Bit  ->  Bit 

(atratogp  (1  3  3  0)  gather  (S  B  B)  proc  0]  . 
op  .oflo.  I  nt  Bit  ->  Bool  Catratogjr  (1  3  0)  proc  Bt]  . 

var  T  B  t  Bit  . 

oq  oif  trao  thoa  T  olao  B  fl  o  t  . 
oq  olf  falao  thoa  T  olao  B  f 1  o  g  , 

oq  B  oflo  B  o  trao  . 

var  P  q  B  :  Bool  . 
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vkr  A  B  C  D  :  Elt  . 


•••  if  diatribatloB 

aq  aif  aif  P  tkaB  Q  alaa  B  fi  tbaa  A  alaa  B  fi  ■ 

aif  P  tbaa  aif  Q  tbaa  A  alaa  B  fi  alaa  aif  ■  tbaa  A  alaa  B  fi  fi  . 

•••  logical  aabatitatioB 

oq  aif  P  tbaa  aif  P  tbaa  A  alaa  B  fi  alaa  C  fi  ■ 
aif  P  tbaa  A  alaa  C  fi  . 

oq  aif  P  tbaa  C  alaa  aif  P  tbaa  A  alaa  B  fi  fi  ■ 
aif  P  tbaa  C  alaa  B  fi  . 

oq  aif  P  tbaa  aif  Q  tbaa  aif  P  tbaa  A  alaa  B  fi  alaa  C  fi  alaa  D  fi  ■ 
aif  P  tbaa  aif  Q  tbaa  A  alaa  C  fi  alaa  D  f i  . 

aq  aif  P  tbaa  aif  Q  tbaa  C  alaa  aif  P  tbaa  A  alaa  B  fi  fi  alaa  D  f i  •• 
aif  P  tbaa  aif  Q  tbaa  C  alaa  A  fi  alaa  0  fi  . 

aq  aif  P  tbaa  D  alaa  aif  Q  tbaa  aif  P  tbaa  A  alaa  B  fi  alaa  C  fi  fi  ■ 

aif  P  tbaa  D  alaa  aif  Q  tbaa  B  alaa  C  fi  fi  . 

oq  aif  P  tbaa  0  alaa  aif  Q  tbaa  C  alaa  aif  P  tbaa  A  alaa  B  fi  fi  fi  ■ 

aif  P  tbaa  0  alaa  aif  Q  tbaa  C  alaa  B  fi  fi  . 

oado 

objaet  PBOOP-IIT  ia 

pratoctiag  TUFTH-TALOE  , 
protactiag  IBT  . 
pratoctiag  PBOOF*Tk0n[IBT]  . 

op  _<t_  :  lat  lat  ->  Baal  Cprac  61]  . 
ap  .<aa.  i  lat  lat  ->  Baal  Cprac  61]  . 
ap  .>s_  i  lat  lat  •>  Baal  Cprac  61]  . 
ap  .>aa_  I  lat  lat  •>  Baal  Cprac  61]  . 

aar  A  B  t  lat  . 

aq  A  <a  A  ■  falsa  . 
aq  A  <sa  A  ■  traa  . 
aq  A  >s  A  a  falsa  . 
aq  A  >sa  A  ■  traa  . 

aq  0  <s  1  ■  traa  . 
aq  0  <sa  1  ■  traa  . 
aq  0  >s  1  ■  falsa  . 
aq  0  >aa  1  ■  falsa  . 

aq  A  a  1  >#■  B  ■  ((A  >wm  B)  ar  <A  B  -  1))  . 
aq  A  a  1  <#■  B  ■  ((A  <s  B  -  1)  ar  (A  asa  B  ■>  D)  . 
aq  A  a  -1  >um  B  a  i  >•  g  , 

aq  A  a  -1  <aa  B  a  ((g  g)  ar  (A  -  1  aaa  a))  . 

aada 

sbjact  PBOOP*CASB  is 
cart  Bart  . 

ap  p  I  Bart  ->  Baal  . 

ap  alf.tbaa.olsa_fi  i  Baal  Bart  Bart  ->  Bart  . 
ap  aif_tkaa_alaa_fi  i  Baal  Baal  Baal  •>  Baal  . 

aar  B  t  Baal  . 

aar  SI  B3  t  Bart  . 

aq  pCaif  B  tbaa  SI  alaa  Sa  fi)  - 
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6  Verification  of  Security  in  OBJ 

6.1  Introduction 

This  section  discusses  the  0BJ3  system  [GW88]  and  its  usefulness  in  the  verification  of  security 
properties  in  operating  systems.  In  addition,  an  example  of  an  0BJ3  specification  of  a  simple 
operating  system  with  security  properties  is  presented. 

6.1.1  Using  OBJS  to  Verify  Security 

This  section  will  discuss  ways  in  which  0BJ3  may  be  used  to  verify  security.  The  general  format  is 
meant  to  correspond  to  [CM81],  which  compares  the  specification  systems /languages  HDM,  Special, 
Ina  Jo,  FDM,  Gypsy,  and  AFFIRM.  The  types  of  security  properties  which  are  of  interest  include 
the  following  (description  taken  from  [Lan83]): 

•  Simpk  security  condition.  A  subject  can  read  an  object  only  if  the  security  level  of  the  subject 
is  at  least  that  of  the  object. 

•  ^-property.  A  subject  can  modify  an  object  in  a  manner  dependent  on  an  object  O2  only 
if  the  security  level  of  0i  is  at  least  that  of  O3. 

Suggestions  for  the  implementation  of  information  fiow  models  and  take-grant  models  will  be  dis¬ 
cussed  in  the  following  sections. 

Information  Flow  Models  0BJ3  does  not  have  any  tools  specifically  designed  for  verifying 
security,  unlike  HDM  (which  has  an  associated  multilevel  security  formula  generator).  Information 
flow  analysis,  which  focuses  on  the  transfer  of  information  between  objects,  would  be  difficult  to 
perform  directly  in  0BJ3.  This  is  partially  caused  by  OBJS’s  lack  of  the  concept  of  state:  0BJ3 
may  only  reduce  terms  in  isolation,  not  sequences  of  terms.  Thus,  there  is  no  way  to  directly 
implement  side  effects.  However,  one  can  get  around  this  problem  by  implementing  state  as  an 
OBJS  object.  For  example,  one  might  define  a  module  ARCHirECTUBE  which  contains  sorts 
Memory,  Register,  and  Mar,  then  define  specific  operations  which  modify  items  having  these  sorts. 
Undesirable  information  flow  would  occur  when  one  of  the  operations  causes  information  to  be 
moved  improperly  within  the  items.  For  example,  if  sort  Memory  could  be  divided  into  private 
and  public  parts,  then  undesirable  information  flow  would  occur  if  items  located  in  the  private  area 
could  be  moved  into  the  public  area.  One  could  attempt  to  determine  whether  this  could  occur  by 
formulating  a  boolean  expression  which  stated  that  the  information  had  been  moved  improperly. 
H  the  system  reduced  this  expression  to  boolean  true,  then  the  system  clearly  permits  undesirable 
flow. 

One  disadvantage  of  the  above  technique  is  that  the  system  must  be  "tricked"  into  doing  the 
analysis  of  information  flow.  It  is  possible  that  the  rewrite  engine  will  not  "find”  the  appropriate 
sequence  of  events  which  wiU  cause  undesirable  information  flow  in  a  reasonable  amount  of  time; 
thus,  one  cannot  rely  upon  a  false  reply  to  an  expression  stating  undesirable  flow.  In  addition, 
covert  channels  cannot  always  be  detected  by  this  method  (particularly  those  which  rely  upon 
timing  or  system  characteristics,  such  as  page  fault  rate). 

Take-Grant  Models  Thke-grant  models  use  digraphs  with  labeled  arcs.  Each  label  defines 
whether  the  vertex  at  the  arc’s  origin  has  a  particular  "right"  over  the  vertex  at  the  end  of  the  arc. 
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In  this  context,  rights  refer  to  the  ability  to  take  or  grant  access  rights  to  another  node.  Take-grant 
models  are  used  to  answer  the  question  “Can  a  subject  (node)  A  gain  access  to  an  object  (node) 
B?” 

0BJ3  provides  a  natural  method  of  analysis  for  this  model.  An  object  LABELED-DIGRAPH 
can  be  defined;  this  object  would  export  functions  which  perform  graph  traversals  and  the  sort 
Labeled-digraph.  Traversal  from  one  node  to  the  other  would  depend  upon  the  labeling  of  the  arc 
between  them;  for  example,  if  node  A  has  take  rights  over  node  B,  then  any  node  C  which  has  a 
path  to  B  would  also  have  a  path  to  A.  Similarly,  if  node  B  has  grant  rights  over  node  A,  then  any 
node  C  which  has  a  path  to  B  would  have  a  path  to  A.  The  user  could  then  instantiate  (view)  a 
Labeled-digraph  item  with  the  desired  configuration.  Finally,  the  user  would  request  the  system 
to  reduce  an  expression  declaring  that  a  path  exists  between  a  particular  subject  and  object.  An 
aflEinnative  result  would  indicate  that  the  subject  could  gain  rights  to  the  object;  a  negative  result 
would  indicate  the  opposite. 

Unlike  the  information  flow  method,  all  answers  returned  by  0BJ3  are  conclusive.  Of  course, 
the  user  is  still  at  the  mercy  of  the  rewrite  engine  and  may  find  that  large  graphs  require  a  great 
deal  of  computation.  Additionally,  covert  channels  are  still  not  addressed. 

6.1.2  General  Observations 

0BJ3  has  a  fairly  easy  S3mtax  to  learn,  although  it  is  somewhat  unforgiving  regarding  punctuation. 
Since  OBJ3  spedfications  are  executable  —  via  term  rewriting  —  they  are  somewhat  easier  to  work 
with  than  purely  spedficational  systems.  Not  all  properties  may  be  proven  using  term  rewriting 
(and  others  cannot  be  proven  efficiently  in  this  fashion);  this  implies  that  some  human  intervention 
is  necessary. 

OBJ3  does  not  spedflcally  provide  tools  which  manipulate  security  properties  or  permit  spec¬ 
ification  of  concurrency.  However,  it  is  possible  to  compensate  for  this  by  building  objects  which 
provide  such  concepts  as  state  and  input /output  histories. 

6.2  An  OBJ3  Specification  o*  A  Simple  Operating  System 

In  this  section,  an  0BJ3  specification  of  a  secure  operating  system  will  be  presented.  The  operating 
system  is  based  on  the  one  described  in  [LevSO].  In  brief,  the  system  may  be  broken  down  into  three 
components:  the  architecture,  the  supervisor,  and  the  user  processes.  Each  of  these  components 
will  be  described  by  one  or  more  0BJ3  objects.  The  following  sections  consist  of  a  description  of 
the  component  being  defined  by  the  object,  the  0BJ3  code,  and  asummary  of  the  code. 

6.2.1  Architecture 

The  architecture  used  in  this  system  is  very  simple.  It  consists  of  a  memory,  a  collection  of  user 
registers,  and  a  memory  management  unit  (mmu).  These  components  are  all  built  out  of  registers, 
each  of  which  contains  a  single  word  of  information. 

The  following  operations  may  be  performed: 

•  Fetch. 

•  Store. 

•  IVap. 
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The  fetch  instruction  causes  information  transfer  from  a  memory  register  into  a  user  register;  the 
store  instruction  transfers  information  from  a  user  register  to  a  memory  register,  and  the  trap 
instruction  transfers  control  to  the  supervisor  (generally  so  that  a  supervisor  —  privileged  — 
instruction  may  be  executed). 

The  following  pages  contain  the  object  definition  of  object  ARCHITECTURE, 
ebj  ARCHITECTURE  is 

•••  Tlks  sorts  previdsd  by  ARCHITECTURE 

sorts  Rogblock  Rogistor  Block-aua  Oisplscoaoat  . 

sorts  Koaory  Block  Iteu  . 

s««  laportod  aodulos 

protoctiag  IHT  . 

protoetiag  BOOL  . 

•••  A  partial  ordariag  of  sorts 
sttbsort  lat  <  Oisplacaaaat  Bloek-aw 
subsort  Block  <  Noaory  . 
subsort  Iteu  <  Rogblock  . 

••• 

•••  rogistor  oparatioas 
sso 

op  :  lat  lat  ->  Rogistor  . 

op  ( _ )  :  Rogistor  Rogblock  ->  Rogblock  . 

op  _LJ  :  Rogblock  lat  ->  Rogistor  . 

op  Rog-val  :  Rogistor  ->  lat  . 

op  Rog-id  :  Rogistor  ->  lat  . 

op  Sot-rog  :  Rogblock  lat  lat  ->  Rogblock  . 

op  ail  :  ->  Rogblock  . 

op  ailrogistor  :  ->  Rogistor  . 

op  Cloar-rogblock  :  Rogblock  ->  Rogblock  . 

••• 

•••  aoaory  oparatioas 
••• 

op  (..)  :  lat  Rogblock  ->  Block  . 
op  Block-id  :  Block  ->  lat  . 
op  Block-coatoats  :  Block  ->  Rogblock  . 
op  Cloar-block  :  Block  ->  Block  . 
op  :  Black  Noaory  ->  Noaory  . 
op  ooa  :  ->  Noaory  . 

op  Noa  :  Noaory  Block-aua  Displacoaaat  ->  Rogistor  . 
op  Sot-aaa  :  Noaory  Block-aua  Displacoaaat  lat  ->  Noaory  . 
op  Sot-aoa  :  Noaory  Block-aua  Rogblock  ->  Noaory  . 
op  :  Noaory  Block-aua  ->  Rogblock  . 
op  Cloar-aoa  :  Noaory  ->  Noaory  . 

••• 

•••  NHU  oparatioas 
ooo 

op  :  Rogistor  Rogistor  ->  Nau  . 
op  Nor  :  Iteu  lat  ->  Rogistor  . 
op  Sot-aar  :  Nau  lat  lat  ->  Iteu  . 
op  Rogblock-to-aau  :  Rogblock  ->  Nau  . 

Bquatioaal  Part  ooo 


—  J  thoa  (1  I')  oUo  RbCJ]  fi  . 

-  -1  . 


oq  Sot-rog(ail.  1,  1')  ■  ail  . 
oq  Sot-rog(((l  I*)  Rb),  J,  E)  - 

if  1  —  J  thoa  (1  I)  Rb  also  (1  I>)  Sot-rog(Rb.  J.  K)  fi  . 
oq  Claar-rogblock(ail}  ■  ail  . 

oq  Cloar-rogblock((I  1*)  Rb)  ■  (1  0)  Cloar-rogblock(Rb) 


n 

Rb  RL 

SB'  : 

1  Bl* 
D'  : 


ooo 

var 
var 
var 

var  Rb  Rb’ 
var 
var 
var 

var  H  N> 

ooo 

ooo  rogistor 
ooo 

oq  ailCn  ■  ailrogistor  . 
oq  ((1  1’)  Rb)CJl  -  if  1 
oq  Rog-val(  1  1’  )  ■  1'  . 
oq  Rog-val  (  ailrogistor  ) 
oq  Rog-id(  1  1’  )  -  1  . 


6?.: 

Rogistor  . 

:  Rogblock 
Block-aua  . 

iiHf^lo^oa 

Noaory  . 
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••• 

•••  aMory 
••• 

lleck-id(I  Rb)  -  I  . 
llock-coat«Bta(I  Rb)  ■  Rb  . 

Cl««r-blo«k(  I  Rb)  -  I  Cl««r-r«gbleck(Rb)  . 

«<{  N«b(B1  M.  B.  D)  - 

i<  B  Bleck-idCBl)  than  (Bloek-eeBt«:ita(Bl))CO]  ala*  MaaCM.B.D)  lx  . 
aq  NaaCaea,  B,  0)  ■  ailragiatar  . 
aq  Sat<-aaa(Bl  N,  B.  D,  J)  - 

ii  B  ■■  Bleek-id(Bi)  than  (B  Sat-rag(Bloek-coa«aata(Bl).  0.  J))  M 
alaa  B1  Sat-aaaCK.B.O.J)  ii  . 
aq  Sat-aaaCBl  M.  B,  Rb)  ■ 
if  B  —  Black-idCBl)  tbaa  (B  Rb)  R 
alaa  11  Sat-aaaCR.B.Rb)  ti  . 
aq  Sa«>Baa(aaa.  B.  D,  J)  -  aoa  . 
aq  (11  H)  D]  - 

il  1  llack-idOll)  tbaa  llock-«aataata(ll) 
alaa  M[U  ii  . 

aq  Claar-aaadl  H)  ■  Claar-black(ll)  Claar-aaa(H)  . 

aq  Claar-aaa(aaa)  ■  aoa  . 
aaa 

•••  aan 

aq  Rar(R  R>.  2)  - 

if  Z  —  0  than  R  alaa  R*  fl  . 

aq  Sat>aar(R  R*.  Z.  Z‘)  ■ 

if  Z  —  0  tbaa  (Z  Z')  R*  alaa  R  (Z  Z>)  fi  . 

aq  Ragbloek-ta-aBa(  Rb  )  ■  (RbCO]  RbCl])  . 

aado  . 

The  most  important  sorts  provided  by  Afi.CHlT£CTnR£  are  Memory,  Mmn,  Register,  and 
Block.  Sort  Register  is  defined  to  be  a  pair  of  integers;  the  first  in  the  pair  gives  the  register  id 
number  and  the  second  is  the  value  contained  in  the  register.  Sort  Block  contains  an  id  number 
and  sequence  of  registers  Sort  Memory  is  defined  to  be  a  collection  of  blocks.  Sort  Mmu  is  defined 
as  a  pair  of  registers.  Note  that  this  specification  does  not  require  a  particular  sixe  memory;  for 
brevity’s  sake  it  was  decided  that  the  user  would  be  responsible  for  instantiating  the  proper  size 
memory. 

ARCHITECTBRE  provides  many  operations  for  manipulating  its  sorts;  among  them  are  oper¬ 
ations  for  concatenation  of  registers  (to  form  blocks),  an  array-style  notation  for  getting  the  value  of 
a  particular  register  in  a  register  block  or  in  memory,  operations  to  clear  memory/blocks/registers 
(clear  means  set  to  zero),  and  operations  for  chan^^g  the  value  of  a  particular  register  in  memory. 

It  is  worth  noting  that  the  sorts  Displacement  and  Block-num  have  been  defined  as  supersorts 
of  sort  Int  (integer).  This  indicates  that  all  integer  values  are  also  Displacements  (or  Block-num) 
and  also  implies  that  there  may  be  Displacements  (or  Block-num)^ which  are  not  integers. 


6.2.3  Supervisor 

The  supervisor  is  fairly  complicated,  so  four  objects  have  been  used  to  define  it:  OPSYS,  SUPERVI¬ 
SOR,  SUP-OPS,  RUN-SUPERVISOR.  The  object  OPSYS  contains  objects  which  are  "borderline” 
between  the  architecture  of  the  system  and  the  system’s  supervisor.  For  example,  OPSYS  de¬ 
fines  the  state  of  the  system  (State)  as  consisting  of  the  mode  of  operation,  the  contents  of  the 
memory,  the  contents  of  the  mmn,  and  the  contents  of  the  user  registers.  OPSYS  also  provides 
functions  which  allow  the  manipulation  of  State’s  components.  Additionally,  OPSYS  provides  the 
unprivileged  mode  instructions  described  earlier. 

sbj  OPSTS  is  •xtsAdiag  ARCHZTICTWI  . 
sort  Stat*  . 

op'laSttal-atata  :  Mod#  Maeorv  lagbleek  Ragbleek  •>  State  . 
op  Sot-atato-rog  ;  Stato  Zat  lat  ->  State  . 
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op  Sot-oto«0'>rog 
op  Sot-Stoto-BBU 
op  Sot-OtOtO-BKU 
op  Sot-stoto-Boa 
op  Sot-atoto-aoa 
op  Got-otato-rog 
op  Got-stato-aau 
op  Got-atato-aoa 
op  Got-atato-aod 
op  priTiloKod 
op  unpriTxlogod 


Stato  Rogblock  ->  Stato  . 

Stato  lat  lat  ->  Stato  . 

Stato  Rogblock  ->  Stato  . 

Stato  Block-nua  Oiaplaeoaoat  lat  ->  Stato 
Stato  Moaory  ->  Stato  . 

Stato  ->  Rogblock  . 


op  Got-atato-BBU  :  Stato  ->  Mau  . 
op  Got-atato-BOB  :  Stato  ->  Hoaory  . 
op  Got-atato-aod  :  Stato  ->  Modo  . 
op  prioilogod  ;  ->  Modo  . 
op  unpriTxlogod  :  ->  Modo  . 
ooo  uapriTilogod  aodo  iaatructicaa 
op  Poteh  :  Stato  Zat  Zat  Zat  ->  Stato 
op  Storo  :  Stato  Zat  Zat  Zat  ->  Stato 
op  Ce^ttto  :  Stato  Zat  Zat  ->  Stato  . 
op  Txmp  :  Stato  ->  Stato  . 
oara  MM':  HoaaTy  . 

Tara  Rb  Rb*  :  Rogblock  . 

Tara  Mu'.:  hm  . 

Tara  S  5'_:  Stato  . 

Tara  D  :  Oiaplaeoaoat  . 


Tara  Mo  Mo'  :  Modo  . 
oc  Got-atato-rogC  Zai 


04  Got-atato-rogC  Zaitial-atato(No.  M,  Rb.  Mn)  )  >  Rb  . 

04  6ot-atato-aan(  Zaitial-atatoCMo,  M,  Rb.  Mu)  )  >  Mu  . 

04  Got-atato-Boa(  Zaitial-atatoCMo.  M.  Rb.  Mu)  )  ■  M  . 

04  Got-atato-Bod(  Zaitial-atatoCMo.  M.  Rb.  Mu)  )  ■  Mo  . 

04  Got-atato-rogC  Sot-atato-aoaCZaitial-atatoCIto,  M.  Rb.  Mu).  B.  0.  I  ))  ■  Rb 

04  Got-atato-aattC  Sot-atato-aoaCZaitial-atatoCMo,  M.  Rb.  Mu).  B.  0.  B  ))  ■  Mu 

04  Got-atato-rogC  Sot-atato  aanCZaitial-atatoCMo,  M,  Rb.  Mu).  Z.  J  ))  ■  Rb  . 

04  Got-atato-aoaC  Sot-atato-aauCZaitial-atatoCMo,  M.  Rb.  Mn).  Z.  J  ))  ■  M  . 

04  Got-atato-aauC  Sot-atato-rogCZaitial-atatoCMo,  M.  Rb.  Hu).  Z.  J  ))  ■  Mu  . 

04  Got-atato-aoaC  Sot-atato-rogCZaitial-atatoCNo,  M.  Rb.  Mn).  Z.  J  ))  ■  M  . 

04  Sot-atato-aoaCZaitial-atatoCMo.  M.  Rb.  Mn).  B,  0.  B  )  > 

Zaitial-atatoCMo.  Sot-aaaCM.  B.  0.  B).  Rb.  Mn)  . 

04  Sot-atato-aoaCZaitial-atatoCMo.  M.  Rb.  Mn).  M'  )  ■ 

Zaitial-atatoCMo.  M' .  Rb.  Mn)  . 

04  Sot-atato-rogCZaitial-atatoCMo,  M.  Rb.  Mn).  Z,  J)  * 

Zaitial-atatoCMo.  M,  Sot-rogCRb.  Z.  J).  Hu)  . 

04  Sot-atato-rogCZaitial-atatoCMo.  M.  Rb.  Mu).  Rb')  ■ 

Z^tial-atatoCMo.  M,  Rb',  Mn)  . 

04  Sot-atato-aauCZaitial-atatoCMo,  M,  Rb,  No),  Z,  1)  * 

Zaitial-atatoCMo,  M,  Rb,  Sot-aarCNu,  Z.  J)  )  . 

04  Sot-atato-aanCZaitial-atatoCMo,  M.  Rb,  Mn),  Mn')  ■ 

Zaitial-atatoCMo,  M,  Rb.  Mn'  )  . 

04  Sot-atato  aanCZaitial-atatoCMo.  M.  Rb,  Mu),  Rb')  > 

Zaitial-atatoCMo.  M,  Rb,  Rb'  )  . 

04  Patches.  Z,  J,  K)  -  Sot-atato-rogCS,  Z, 

Rog-TolCMoaC  Got-atato-aoaCS) .  Rog-TalCRarCOot-atato-MnCS),J)).  R)))  . 

04  StoroC  S.  Z,  J,  I)  ■  Sot-atato-BoaC  S, 

Rog-TolCMarCGot-atato-amCS)  .J) ) . 

I. 

Rog-ral C  CGot-atato-rogCS) ) CZ] ) )  . 

04  Trmpi  Zaitial-atatoConpriTilogod,  M,  Rb.  Mn)  )  • 

Z^tial-atatoCpriTilogod,  M,  Rb.  Mn)  . 


The  second  object  which  is  nsed  to  define  the  system  snperrisor  is  nnmed  SUPERVISOR.  This 
object  defines  the  supervisor  state  (Snpstate)  as  a  collection  of  supervisor  variables  and  the  system 
state  (State)  defined  previously.  The  supervisor  variables  defined  are:  the  current  process  id  (CP), 
a  list  containing  each  process’  authorisation  level  (PAL),  a  save  area  for  each  process’  user  registers 
and  mapping  renters  (SR,  SMAR),  and  information  regarding  the  security  level  of  each  block 
in  the  system:  authorisation  level  (BAL),  status  (BAP),  access  count  (BAG),  attached  to  device 
(BDF). 

In  addition  to  providing  operations  which  read/set  each  of  these  supervisor  variables,  SU- 
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PERVISOR  defiaes  authorization  levels  (Alevel).  This  is  done  by  taking  advantage  of  the  subsort 
construct  to  declare  integers  as  a  subsort  of  Alevels,  providing  two  operations  Syshi  and  Syslo  which 
are  defined  to  return  sort  Alevel,  and  then  defining  the  value  of  the  <  operator  when  applied  to 
integers  and  Alevels.  It  is  interesting  to  note  that  only  two  equations  are  needed  in  addition  to  the 
subsort  and  the  op  definitions.  The  first  of  these  equations  declares  that  J  <  Syshi  is  true  for  ail 
integers  I,  and  the  second  declares  that  I  <  Syslo  is  false  for  all  integers  I.  Since  Int  is  a  subsort  of 
Alevel,  all  Ints  are  automatically  of  sort  Alevel;  however,  the  standard  integer  <  operation  will  be 
used  to  compare  them.  This  combination  of  declarations  ensures  that  all  ‘‘integer”  authorization 
levels  will  automatically  fall  between  Syshi  and  Syslo. 

Amother  item  worth  noting  is  the  use  of  overloading  to  simplify  setting  values  in  SMAR  and 
SR.  This  permits  the  user  to  use  the  same  function  call  (Set-Smar/Set-Sr)  to  modify  either  one 
of  the  SMAR  registers  or  the  entire  SMAR  block.  It  is  also  interesting  to  observe  that  object 
SUPERVISOR  imports  OPSYS  via  an  extmding  clause;  this  permits  SUPERVISOR  to  add  new 
data  items  having  sorts  defined  oti|pnally  in  OPSYS. 

•bj  SSPKRVISOR  is 
protect iag  XIT  . 
protect tag  BOOL  . 
pretoctiag  iRCHITSCTUBZ  . 
oztoadiag  OPSTS  . 

•orto  Supetote  Hovel  Pid 
•orte  Block'iaio-lipt  Bleck-iaie 
•ubaort  lat  <  ilevel  . 
onboert  Pid  <  lat  . 
op  Sfthi  :  ->  Alevel  . 

op  Syelo  :  ->  Alevel  . 

op  aillcvel  :  >>  Alevel  . 

op  (_)  _  :  lat  Alevel  Begbleek  ->  Begblock 

op  .C.J  :  Begblock  Zat  •>  Alevel  . 

op  :  lat  Alevel  ->  Bool  . 

«p  Best-Cp  :  Pid  -'>  Pid  . 

op  Cp  :  Si9atete  ->  Pid  . 

op  Pel  ;  Supstete  Pid  ->  Alevel  . 

op  Sr  :  Snpetete  Pid  ->  Begblock  . 

op  Saar  :  Snpatate  Pid  •>  Begblock  . 

op  Bel  :  Si^atate  lat  ->  Alevel  . 

op  Bap  :  St^atate  Xat  ->  Bool  . 

op  Bac  :  Si^tate  Zat  ->  Zat  . 

op  BdS  :  Si^atate  Zat  ->  Bool  . 

op  Set-Cp  :  St^etate  Pid  ->  St^atate  . 

op  Set-Pal  :  Sopatato  Pid  Zat  ->  Si^atate  . 

op  Sot-Sr  :  Snpatate  Pid  Begblock  ->  Si^atate  . 

op  Set-Saar  :  Snpatate  Pid  Begblock  ->  Snpatate  . 

op  Set-Bal  :  Si^atate  Zat  Alevel  ->  Si^atate  . 

op  Set-Bap  :  Sapatate  Zat  Bool  ->  St^tate  . 

op  Set-Bac  :  Svpstmts  Zat  Zat  ->  Si^tate  . 

op  Set-BdS  :  Simtate  Zat  Bool  ->  Si^tate  . 

op  Set -State  :  Si^tate  ->  State  . 

ep  Set-State  :  Si^atate  State  ->  Snpatate  . 

ep  Rake-bleck  :  Zat  Alevel  Beel  Zat  Beel  ->  Bleck-iaie  . 

op  bal  :  Bleck-iaSe  ->  Alevel 

ep  bap  :  Bleck-mte  ->  Beel  . 

ep  bac  :  Bleck-iaZe  ->  lat  . 

ep  bdf  :  Bleck-iaZe  ->  Beel  . 

ep  aet-bal  :  Bleck-iaSo  Alevel  ->  Bleck-iaSe  . 

ep  aet-bap  :  Bleck-iafe  Beel  ->  Bleck-iaSe  . 

ep  aet-bac  :  Bleck-iaSe  Xat  ->  Block-iafe  . 

ep  aet-bdf  :  Bleck-iaSe  Beel  ->  Bleck-iaSe  . 

ep  aet-bal-liat  :  Bleck-iafe-liat  Zat  Alevel  ->  Bleck-iafe-liat  . 
ep  aet-bap-liat  :  Bleck-iaSe-liat  Zat  Beel  ->  Bleck-iafe-liat  . 
ep  aet-bac-liat  :  Bleck-iafe-liat  Zat  Zat  ->  Bleck-iafe-liat  . 
ep  aet-bdf-liat  :  Bleck-iafe-liat  Zat  Beel  ->  Bleck-iafe-liat  . 
ep  Bleck-id  :  Bleck-iafe  ->  Zat  . 

ep  :  Bleck-iafe  Bleck-iafe-liat  ->  Bleck-iafe-liat  . 
ep  _LJ  :  Bleck-iafe-liat  Zat  ->  Block-iafe  . 
ep  ail-b  :  ->  Bleck-iafe-liat  . 
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op  ailbleck  :  >>  IXeck-iaio  . 

op  Znit-aupototo  :  Pid  kogbleck  Moaory  Hoaory  Bloek-iafe-liot 
Stoto  ->  St^tota  . 

Toro  P  P’  :  pid  1 
Toro  A  A*  :  Rogbleck 
Taro  Ai,Ai*  :  Alovol  . 

Tara  Sri  Sri*  :  Noaory  . 

Tara  Sal  Sal*  ;  Noaory  . 

Tara  Nil  Bil'  : .Block-iaio-liat  . 

TvaHl'u  IS^B*?*Bogiator  . 


Tara  St  St*  :  ftato  . 
Tara  Su  Su*  :  svftmt*  . 

Tara  No  Ho'  :  Noaory  . 


Tara  Bo  Bo'  :  Bogblock  . 

ooo  loTol  ceapariaoaa 

oq  X  <  Syahi  >  tno  . 

oq  I  <  Syalo  ■  Salao  . 

ooo  gottiag  oloaoata  iroa  a  block  liat 

oq  Block-id(  Nako-block(I.  Ai,  Tl.  1.  T2)  )  -  X  . 

oq  (Bi  Bil)Cxi  ■  if  Block-id(Bi)  —  X  tbon  Bi  olao  BilCX]  Si  . 

oq  ail~bCX]  ■  ailblock  . 

ooo  aottiag  liat  oloaoata  in  block  liat 

oq  aot^b^-liatC  Bi  Bill  X.  Tl)  ■ 

is  Bloek-id(Bi)  —  X  tbon  aot-biq»(Bi.  Tl)  BU 

olao  Bi  aot-b^-liat(Bil.  X,  Tl)  Si  . 

oq  aot-bal-liat(  Bi  Bil.  X.  Ai)  - 

is  Block-id(Bi)  —  X  thoa  aot-bal(Bi.  Ai)  Bil 

olao  Bi  aot-bal*-liat(Bil.  X.  Ai)  Si  . 

oq  aot-bac-liat(  Bi  Bil.  X.  J)  ■ 

is  Bloek-id(Bi)  —  X  tbon  aot-bae(Bi.  3)  Bil 

olao  Bi  aot-bac'-liat(Bil.  X.  J)  Si  . 

oq  aot-bdS-liat(  Bi  BU.  X.  Tl)  - 

is  Block-id(Bi)  —  X  tboa  aot-bdS(Bi.  Tl)  Bil 

oUo  Bi  8ot-bdS>liat(BU.  X.  Tl)  Si  . 

ooo  iatoraal  block  accoaa  roatiaoo 

oq  boKNako-bloSRx.  Ai.  Tl.  B.  T3))  -  Ai  . 

oq  bap(Nako>block(X.  Ai.  Tl.  B.  T3))  >  Tl  . 

oq  bac(Nako-block(X.  Ai.  Tl.  B.  T3))  -  B  . 

oq  bdS(Nako-block(X.  Ai.  Tl.  B.  T3))  -  T3  . 

oq  8ot-bal(Nako-block(X.  Ai.  Tl.  B.  T2) .  Ai')  «  Hako-block(X.  Ai'.  Tl.  B.  T3) 

oq  apt  -bapfHako~b1orkfT ,  Ai.  Tl.  B.  T2).  T3)  ■  Nako-bleek(X.  Ai.  T3.  B.  T2)  . 

oq  80t'*bac(Hako~bloek(X.  Ai.  Tl.  B.  T3).  N)  *  Hako-block(X,  Ai.  Tl.  N.  T2)  . 

oq  aot-bdSCNako-blockCX.  Ai.  Tl.  B.  T2).  T3)  >  Nako>bleck(I.  Ai,  Tl.  B.  T3)  . 

ooo  Boad  Talooa  Sroa  aaporriacr  atato 

oq  Cp(  Xait-a«9atato(  P.  A.  Sri.  Sal.  BU,  St  ))  >  P  . 

oq  Pal(  XBit-8i9atato(  P,  A.  Sri.  Sal,  BU.  St  ).  P')  ■  A[P']  . 

oq  Sr(  XBit-a«^tato(  P,  A,  Sri.  Sal,  BU,  St  ),  P')  ■  Srl^']  . 

oq  Saar(  Xait-ai9atato(  P,  A,  Sri,  Sal,  BU,  St  ).  P’)  ■  Sal[P']  . 

oq  Bal(  Xait-8apatato(  P,  A,  Sri,  Sal,  BU,  St  ).  X)  ■  bal(BU[X])  . 

oq  Bap(  Xait-a«98tato(  P,  A,  Sri,  Sal.  BU.  St  ).  X)  ■  bap(BUCX3)  • 

oq  Bac(  Xait-8apatato(  P.  A,  Sri,  Sal,  BU,  St  ).  X)  •  bac(BU[X])  • 

oq  BdS(  Xait-aapstato(  P.  A,  Sri,  Sal,  BU,  St  ),  X)  «  bdS(BUCX])  . 

oq  Qot-Stato(  Xait-o«patato(F,A,Srl,Sal,BU,St))  •  St  . 

ooo  Brito  Talaoa  eS  aaporriaor  atato 

oq  Sot-CpC  Xait-sapatatoC  P,  A,  Sri,  Sal.  BU.  St  ),  P')  ■ 

XBit-oi9atato(P’ .A.Srl.Sal.BU.St)  . 

oq  Sot-Pal(  XBit-a«^tato(  P,  A,  Sri,  Sal.  BU.  St  ).  P*.  B)  > 
XBit-aapatato(P,  Sot-rog(A,P',B),  Sri,  Sal,  BU,  St)  . 
oq  Sot-SrC  Xait-8apatato(  P,  A,  Sri,  Sal,  BU.  St  ),  P*.  Bo)  ■ 
Xait-ai9atato(P.  A,  Sot-aoa(Sri,  P'.  Bo),  Sal,  BU.  St)  . 
oq  Sot>Saar(  &Ut-aapatato(  P,  A.  Sri,  Sal.  BU.  St  ),  P*.  Bo)  ■ 
Iait-aapatato(P,  A.  Sri,  Sot-aaa(Sal.  P’.  Bo).  BU.  St  )  . 
oq  Sot-Bal(  Xait-aapatato(  P,  A,  Sri,  Sal,  BU.  St  ).  X.  B)  > 
X^t-8i9atato(P.  A,  Sri,  Sal,  aot-bal-liat(BU,X,B).  St)  . 
oq  Sot-B^(  Xait-aapatato(  P,  A.  Sri,  Sal,  BU,  St  ).  X,  Tl)  ■ 
Xait-ai^atatoCP,  A,  Sri,  Sal,  aot-bap-liat(BU.X.Tl),  St)  . 
oq  Sot-Bac(  Xait-8npatato(  P,  A,  Sri.  Sal,  BU,  St  ),  X,  B)  ■ 


149 


Zait-stipatataCP,  1,  Sri.  Sal,  ••t-b«e>liat(Bil,I.I).  St)  . 

•4  S«t-BdS(  Iait-si^t«t«(  P.  i.  Sri,  Sal,  Bil.  St  ),  1,  Tl)  ■ 
X^t-aiipatat«(P,  A,  Sri,  Sal.  ••t-bdi-liat(Bil.Z.Tl).  St)  . 

•4  S«t-Stat«(  ZBit-aiip«t«t«(  P,  A,  Sri,  Sal.  Bil.  St  ).  St')  ■ 
Iait-«iqMtat«(P.  A.  Sri,  Sal.  Bil,  St')  . 

•4  B«zt-Cp(  P  )  -  it  P  ■■  1  than  2  «la«  1  ti  . 

•ado  . 


The  third  object  maJung  up  the  supervisor  component  of  the  system  is  SUP>OPS.  This  object 
contains  the  definitions  of  the  four  privileged  instructions  provided  by  the  system:  Purge,  Raise, 
Get,  Swap.  These  instructions  are  defined  in  detail  in  [LevSO];  a  brief  description  follows  here. 

Purge  is  used  to  set  the  contents  of  a  memory  block  to  sero  and  raise  its  authorization  level  to 
Syshi  (effeetivdy  making  it  unusable  by  a  user  process).  Purging  may  only  take  place  in  privileged 
mode,  and  only  when  no  processes  are  accessing  the  block  and  the  block  is  not  attached  permanently 
to  an  input /output  device. 

Raise  is  us^  to  change  the  status  of  a  block  to  ‘active’  and  change  its  authorization  level  to 
match  that  of  the  current  proceM.  Raise  is  only  performed  on  a  purged  block;  in  effect.  Raise 
makes  a  purged  memory  block  available  to  a  user  process. 

Get  is  used  to  give  a  process  access  to  a  particular  block.  This  is  done  by  setting  the  block’s 
access  count  to  one,  placing  a  pointer  to  the  block  in  the  process’  mmu,  and  setting  to  zero  the 
access  count  of  the  block  that  the  process’  mmu  previously  indicated.  Get  may  only  be  performed 
upon  blocks  that  are  active,  not  currently  being  accessed,  and  having  an  authorization  level  equal 
to  that  of  the  current  process.  This  prevents  a  process  from  using  Get  to  gain  unauthorized  access 
to  another  process’  data. 

Swap  is  a  simple  operation;  it  is  used  to  switch  current  processes.  Swap  is  responsible  for 
transferring  all  of  the  current  process’  user  registers  (and  mmu)  into  temporary  storage  so  that  the 
succeeding  process  cannot  manipulate  it.  Any  process  may  call  Swap. 

It  is  worth  noting  that  object  SUP>OPS  contains  all  the  explicit  security  information.  By  that 
it  is  meant  that  the  security  policy  of  the  system  is  embedded  in  the  four  supervisor  operations 
(i.e.,  processes  may  access  only  blocks  at  the  same  authorization  level).  It  is  in  this  block  that 
the  user  could  modify  security  policy.  For  example,  one  might  wish  to  permit  processes  to  access 
blocks  with  authorization  levels  less  than  or  equal  to  their  own;  this  would  require  modifying  the 
precondition  for  operation  Get.  One  might  also  like  to  specify  both  a  read  and  a  write  authorization 
policy,  such  as  the  one  given  by  the  conjunction  of  *<property  and  simple  security.  These  could  also 
be  accomplished  by  modifying  SXTP-OPS  (and  some  modifications  to  Supstate  in  SUPERVISOR). 


OBJS’s  hierarchical  structure  u  very  useful  for  localizing  secunty  properties, 
•bj  SOP-QFS  ia 
pretectiaf  BOOt  . 

protactiag  IBT  . _ 

pretaetiaf  ABCHZnCIUU  . 
pretectiac  OPSTS  . 

MrtwirttM  SDPnvZSOB  . 
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•q  Pnrg«(  Su,  I)  ■ 

H  (B*c(Stt,l)  «  0)  and  (net  Bdl(Su.  ■))  than 
S«t-Stat«(S«t-Biq>(S«t-Bal(  Su,  B,  Syahi),  B.  aot  Bap(Su.B)). 

Sat-atata-aaaCGat-StataCSu) , 
Cl*ar-s«a(G«t-st«t«-BM(G«t-Stat«(Su) ) ) ) ) 

Su  fi  . 

•q  Rais«(  Su,  B)  > 

H  (aet  Bap(Su,B))  thaa 
Sat-Bap(Sat-Bal(Su,  B,  Pal(Su,  Cp(Su))}, 

B,  trua  ) 

alaa  Su  Si  . 

aq  6at(  Su,  B,  I)  - 

is  Bap(Su,B)  aad  (Bae(Su,B)—  0)  aad 

(BalCSu.B)  —  Pal(Su.Cp(Su))) 

thaa 

Sat-Bae(Sat-Bac(Su.B, 1) , 

Bag-Tal(Mar(6at-atata-BBn(Gat-Stata(Su) ) .K)) , 

aiaa  Su  Si  . 
aq  Sai^CSu)  * 

Sat-Stata( 

Sat-Saar( 

Sat-Sr(Sat-Cp(Su,  Baxt-Cp(Cp(Su))) ,  Cp(Sa), 
6at-atata-rag(6at-Stata(Su) ) ) , 

Cp(Su) , 

0at-atata-«Mi(0at-Stata(Su) ) ) , 

Sat-atata-Batt( 

Sat-stata-rag(Gat-Stata(Su) .Sr(Su,Baxt-Cp(Cp(Su)) ) ) . 
lUgbloek-to-BBu(Saar(Su,  Bart-Cp(Cp(Su))  )))). 
aade  . 


6.2.S  User  Processes 

Both  user  processes  end  the  finsl  portion  of  the  supervisor  will  be  discussed  in  this  section,  as  they 
are  intertwined. 

The  user  process  object  T7S£R>PR0CESS  provides  the  sorts  Instruction,  Instruction*sequence, 
and  Process.  Instructions  are  composed  of  instruction  jnames  and  their  arguments  (zero  to  three  ar¬ 
guments).  Once  again,  overloading  is  used  to  permit  a  ‘variable  number*  of  arguments  in  a  strongly 
sorted  system.  Instruction-sequences  are  simply  ordered  sequences  of  instructions.  Processes  are 
made  up  of  an  instruction  sequence.  No  other  information  was  included  in  Process  at  this  time,  in 
the  interest  of  brevity. 

In  addition  to  these  sorts,  USER-PROCESS  provides  operations  to  remove  an  ixutruction  from 
an  instruction  sequence  or  a  process  and  to  read  (without  removing)  an  instruction. 

The  object  RUN-SUPERVISOR  embodies  the  supervisor  chores  which  correspond  to  process 
manipulation.  This  object  provides  the  sort  System-state,  which  consists  of  the  supervisor  state 
combined  with  the  state  of  the  system  processes  (only  two  processes  provided  in  this  implemen¬ 
tation).  The  operations  provided  by  RUN-SUPERVISOR  are;  Execute  (which  causes  a  process 
to  ‘execute’  one  of  its  instructions),  and  Step  (which  returns  the  System-state  after  the  current 
process  has  executed  an  instruction).  At  present,  processes  are  themselves  responsible  for  calling 
Swap;  however,  if  the  concept  of  fair  scheduling  were  to  be  introduced  it  would  be  in  this  module 
that  the  changes  would  be  placed. 


as«r-^ecMs .  eb j 

is 

eretsctiag  ZBT  . 
pretMtiag  SOPnTZSOR  . 
sort  lastructicB  . 
sort  Xastmetxsa-seqiimc*  . 
sort  Instruetiwi-aaM  . 
sort  Precoss  . 
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•vtaMTt  Xastruetitta  <  Zastruetioa-s^^iiMe*  . 

Do-r«tcb  :  ->  lastmetioB-aMM  . 

•p  Oo-Stor«  :  ->  ZxMtruetiMi-aaM  . 

•p  Do-Tr^  :  ->  Zutrnetiea-MM  . 

•p  Oe-P«rg«  :  ->  XnatroetiaB-nMM  . 

•p  Oo-K*i««  :  ->  Instruct  iea-BM«  . 
op  Do-Cot  :  ->  Zaotruetion-nnno  . 
op  Oo-So^  :  ->  Instruct  iott-Boao  . 

op  Instr  :  Instruct ion-nsno  1st  1st  1st  ->  Instruction  . 
op  Instr  :  Instruct ios-ssno  1st  1st  ->  Instruction  . 
op  Instr  :  Isstructios-sano  1st  ->  Instruction  . 
op  Instr  :  Isstmction-ssno  ->  Instruction  . 

^  ooi  :  ->  Instruction  . 
op  nil-instruction  :  ->  Instruction  . 

op  __  :  Instruction  Isstructicn-soqnoneo  ->  Instruct icn-soqucnco  . 
op  Cot-isstrueticn  :  Instruct ion-soqncnco  ->  Instruction  . 
op  tonoro- instruct  ion  :  Isstruction-soqncnco  ->  Instruct  ion-soquouco 
op  Init-proeoss  :  Isstructicn-soqnsnco  ->  Drocoss  . 
op  Adrsnco  :  Process  ->  Prococs  . 
op  Boad-instruetion  :  Procoss  ->  Instruction  . 


04  Oot-iastruetian(Is  Ins)  «  Is  . 
oq  Bonoro-instructiondn  Ins)  ■  Ins  . 
oq  Bonoro- instruct ian(ooi)  ■  ooi  . 

oq  AdrsneoC  Init-proeoss (Is  Ins))  ■  Init-procoss(Iss)  . 
oq  Adrsnco (  Init-proeoss (ooi))  ■  Init-proeoss (ooi)  . 
oq  Bosd-isstruetion(  Init-procoss(  In  Ins))  ■  In  . 
oq  Bosd-isstrttetion(  Init-proeoss(ooi))  ■  nil-instructien  . 

Wf?j5.jjj..j; 

fn'^4s^x4isw .  ob  j 


obj  BDI-SUPERVISOR  is 
protocting  IBT  . 
protoctisg  USBB-PBOCKSS  . 
protoctisg  SOPBEflSOB  . 
protoctisg  SOP-OPS  . 
protoctisg  ABCXmCraBZ  . 
protoctisg  OPSTS  . 
sort  Syston-ststo  . 

op  Soloct-procoss  :  Syston-ststo  1st  ->  Procoos  . 
op  Isit-syston-ststo  :  Si^tsto  Procoss  Procoss  ->  Syston-ststo  . 
op  Ban  :  Syston-ststo  ->  Syston-ststo  . 
op  Stop  :  Syston-ststo  ->  Syston-ststo  . 
op  Brocuto  :  Si^ststo  Instruction  ->  Si^tsto  . 


Tsrs  Ss  Su*  :  SiMtsto  . 
rsrs  Sst  Sst'  :  Syston-ststo 
rsrs 


oq  SoIoet'proeoss(Init-systcn-ststo(Su,  Proc,  Proc'),  I)  ■ 
ii  I  0  tbon  Proc  olso  Proc’  Si  . 
oq  Stop(Init-syston-ststo(Ss,  Proc,  Proc'))  ■ 
ii  ep(Su)  ■■  0  then 

Isit-syston-ststo (bocuto(  Su,  Bosd-isstmetias(Proc)), 
Adraneo(Proe) , 

Pros') 

olso  Init-systcn-otsto(lsoeuto(Su,  Bond-isstmetion(Ps*c')), 
Pros, 

Adrssco(Proc')  )  Si  . 

oq  Bxocato(  Su,  Isstr(Oo-Potcb,  I,  J,  E))  * 

Sot-Ststo(Su,  Fotcli(Oot-Stato(Su) .  I,  J,  B))  . 
oq  bocuto(  Su,  lsstr(Do-Staro,  I,  J,  E))  ■ 

Sot-Ststo(Sa,  Storo(aot-Ststo(Sa) ,  1,  J,  E))  . 
oq  bocuto(  Su,  lsatr(Do-bap,  I,  J,  E))  • 

Sot-Ststo(Su,  bap«iot-Ststo(Sa)))  . 
oq  bocuto(  Su,  Instr  (Do  -Pargo ,  I))  ■  Purgo(  Su,  I  )  . 
oq  bocuto(  Su,  Instr (Do-Bsiso,  I))  ■  Bniso(  Su,  I  )  . 
oq  bocttto(  Su,  Isatr(0o-4ot,  1,  J))  ■  0ot(  Su,  I,  J  )  . 
oq  boeuto(  Su,  Isstr(Do-SBip))  ■  Saap(  Su  )  . 
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6.2.4  Conclusion 


As  shown  by  the  example,  it  is  possible  to  use  OBJ3  to  specify  a  simple  operating  system.  An 
advantage  of  using  0BJ3  is  that  one  may  write  a  sample  term  defining  the  state  of  the  system 
(including  process  information,  etc.)  and  let  OBJ3  apply  the  reduction  rules.  This  permits  spec¬ 
ifications  to  be  exercised,  which  allows  the  user  to  decide  whether  the  system  the  specifications 
describe  corresponds  to  the  system  the  user  desires.  Additionally,  the  modular  form  of  0BJ3 
specifications  permits  the  user  to  experiment  with,  for  example,  different  security  models  within 
the  system.  The  hierarchical  design  of  an  0BJ3  specification,  combined  with  restricted  forms  of 
importation  should  also  lead  to  easier  maintenance  of  the  specification  by  reducing  the  scope  of 
modifications. 

6.3  An  alternate  security  model 


••• 

•••  This  ssenrity  object  providos  the  eporstions 
•••  uy-rood  sad  My-«rito,  shieh  hsvo  boon 
•••  doliaod  to  eonply  with  tbo  o-proporty  and 
•••  si^lo  soenrity  (DoD  nodol) 

••• 

obj  SECURITY  is  sorts  Security  . 
protect ind  ZIT  . 
protect isR  BOOL  . 
subaorts  Security  <  Znt  . 

see  security  levels 
op  top-secret  :  ->  Security  . 
op  secret  ;  ->  Security  . 
op  clsssiSied  :  ->  Security  . 
op  ceaSidontisl  :  ->  Security  . 

•••  security  operations 
op  level (.)  :  Security  ->  lat  . 

op  asy-resd( _ )  :  Security  Security  ->  Bool  . 

op  ssy-orito(_  _)  :  Security  Security  ->  Bool  . 

op  nsy-doclsssifyC _ )  :  Security  Security  Security  ->  Bool  . 

op  nsy-elsssiSy(_  .  _)  :  Security  Security  Security  ->  Bool  . 
op  _>_  :  Security  Security  ->  Bool  [sssocl  . 

I 

eee  oquntioasl  spociSicstion 
vara  S  T  0  :  Security  . 

•••  sssifn  levels 

oq  level (top-soerot)  ■  4  . 
eq  lovoKsocrot)  ■  3  . 
oq  level (clssailiod)  ■  3  . 
oq  lovoKeeaSidoBtinl)  ■  1  . 
oq  S  >  T  ■  lovol(S)  >  lovoKT)  . 

eee  can  road  deun 

oq  asy-road(S  T)  ■  S  ■■  T  or  loval(S)  >  lovoKT)  . 
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•••  e«n  «rit«  up 

•q  U7-«rit«(S  T)  ■  S  ■■  T  or  1«t«1(T)  >  . 

•••  radactiea/iaerau*  of  clooaifieotioa  lovol  eon  only  bo  don#  by  t-o  loool 
oq  My-doelo«aify(S  T  U)  ■  1oto1(S)  »  lovol(top-aoerot)  and  loooKT)  >  1oto1(U) 
oq  nay-claaaifyCS  T  U)  ■  IotoKS)  loTol(top>aocrot)  and  laval(U)  >  IotoX(T)  . 
onde 
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7  Specification  and  Testing  of  Security  in  EASE 
7.1  Introduction 

In  response  to  the  National  Computer  Security  Center’s  demand  for  A1  certified  systems,  there 
is  increasing  interest  in  verification  systems  that  can  reason  about  specifications.  An  operating 
system  is  A1  certified  if  its  specifications  are  verified  to  be  correct  with  respect  to  a  policy  that 
limits  (1)  the  objects  a  process  can  access  based  on  the  security  level  of  the  process  and  object,  and 
(2)  the  flow  of  information  between  processes  based  on  their  security  levels;  as  discussed  by  Goguen 
and  Meseguer  [GM82b][GM84b]  Feiertag,  et  al.  [FLR77],  and  Rushby  [Rus84],  (2)  subsumes  (1). 
A  number  of  verification  systems  have  been  developed  with  this  need  in  mind,  several  specialized 
to  carry  out  security  flow  analysis. 

Clearly,  program  verification  is  difficult.  However,  verification  of  a  specification  with  respect 
to  the  security  flow  policy  need  not  be  as  difficult  as  verifying  a  large  program  such  as  an  operating 
system  with  respect  to  a  specification  that  fully  describes  what  the  operating  system  does.  The 
security  policy  is  expressed  as  follows:  Given  a  sequence  of  operations  invoked  by  processes  at 
different  security  levels,  an  operation  at  a  given  level  LI  can  interfere  with  the  results  of  an  operation 
at  level  L2  only  if  LI  <  L2.  It  is  difficult  to  verify  a  system  with  respect  to  this  policy,  as  it  entails 
a  proof  that  considers  every  sequence  of  operations.  It  can  be  shown  that  the  verification  effort  can 
be  significantly  simplified  to  just  showing  that  the  individual  specifications  of  operations  satisfy 
a  policy.  However,  this  method  generally  requires  that  the  objects  have  constant  security  levels 
[FLR77].  This  assumption  is  clearly  unacceptable  if  the  specifications  are  at  a  level  of  abstraction 
where  objects  are  shared  among  users  of  different  security  levels  -  clearly  the  case  for  most  operating 
systems.  There  are  various  tricks  for  converting  a  specification  that  allows  for  mutable  security 
levels  to  one  in  which  the  security  levels  are  constant,  but  at  the  cost  of  significantly  increasing  the 
cost  of  certification  of  the  implementation  -  by  verification,  testing,  etc. 

Furthermore,  it  does  not  make  sense  for  verification  to  be  the  only  supported  certification 
method.  Most  specifications  will  contain  errors  that  are  better  detected  by  conventional  testing. 
Furthermore,  although  not  mandated  for  Al  certification,  verification  of  a  system’s  specifications 
does  not  guarantee  system  correctness;  errors  can  certainly  occur  in  an  implementation.  Although 
verification  of  the  implementation  of  complex  operating  systems  is  beyond  the  stamina  of  human 
and  mechanical  verifiers,  verification  of  abstractions  below  the  top-level  operating  system  interface 
is  feasible.  However,  at  the  more  detailed  levels  the  assumptions  underlying  the  mechanical  flow 
analyzers  are  no  longer  valid. 

Accordingly,  this  section  presents  two  implemented  tools  that  can  assist  in  the  testing  of 
operating  systems  with  respect  to  security  policies;  the  tools  can  be  used,  in  principle,  at  any  level 
of  abstraction. 

The  first  tool  is  based  on  the  Final  Algebra  Specification  and  Execution  system  (FASE) 
[KJA83],  and  would  be  used  to  test  specifications  with  real  input  values.  FASE  uses  an  exe¬ 
cutable  specification  language  which  is  operational  in  style,  elements  being  represented  in  terms 
of  their  observable  behavior.  The  style  allows  for  specifications  that  are  highly  abstract  but  to  a 
great  extent  executable.  FASE  is  implemented  in  Lisp  and  allows  the  intermixing  of  Lisp  code  and 
FASE  specifications. 

To  facilitate  the  testing  of  an  operating  system  (and  its  specification),  using  FASE  we  have 
specified  a  Secure  Resource  Manager  (SRM),  a  generic  template  of  an  operating  system.  The  SUM 
specification  can  be  specialized  to  a  specification  of  a  particular  operating  system;  the  SRM  is  quite 
general  and  handles  most  features  of  modem  operating  systems. 
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The  second  tool,  called  the  PLANNER,  is  used  to  derive  a  sequence  of  operations  that  exhibits 
a  security  flaw,  most  often  a  covert  channel  for  information  flow.  The  PLANNER  is  based  on 
classical  methods  of  AI  planning,  specialized  to  achieve  goals  concerned  with  information  flow. 
The  PLANNER  attempts  to  achieve  a  goal  wherein  one  of  a  process’  visible  registers  acquires  a 
value  different  from  its  value  in  an  initial  state,  the  change  being  caused  by  a  process  at  a  level  not 
less  than  or  equal  to  that  of  the  original  process.  The  PLANNER  uses  a  backwards-based  search 
strategy.  To  make  the  search  informed,  the  planner  has  heuristics  that  identify  the  operations 
that  are  most  likely  to  be  useful  in  achieving  a  goal.  The  planner  can  also  be  used  to  determine 
a  measure  of  the  channel  capacity  associated  with  a  particular  sequence  of  insecure  operations 
through  determining  the  number  of  possible  values  assignable  to  unbound  variables  in  the  plan  - 
in  essence,  the  uncertainty  of  the  information  flow.  The  PLANNER  is  implemented  in  Prolog. 

Although  these  two  tools  can  be  used  independently,  they  csm  be  used  together  in  two  ways. 
For  example,  the  FASE  tool  can  be  used  to  determine  the  initial  and  final  states  associated  with  a 
sequence  of  operations  suspected  to  be  a  subsequence  of  an  insecure  sequence;  then  the  PLANNER 
can  determine  a  prefix  and  suffix  to  this  sequence  that  achieves  the  unwanted  flow.  In  addition,  the 
FASE  tool  can  be  used  to  test  partial  plans  produced  by  the  PLANNER,  the  plans  being  extended 
by  the  user  if  the  PLANNER  becomes  involved  in  long  and  fruitless  searches. 

The  tools  are  demonstrated  with  respect  to  a  simple  operating  system  specification  developed 
by  Millen  [Mil79].  This  operating  system  provides  user  operations  to  read  and  write  memory,  and 
system  operations  to  swap  processes,  and  purge  and  claim  memory  blocks,  the  memory  blocks 
accessible  only  indirectly  through  segment  registers.  Not  surprisingly,  the  system  contains  a  covert 
channel,  the  heart  of  which  is  the  flow  through  the  purging  of  a  bloc'^  at  one  security  level  and 
claiming  of  the  same  block  at  a  different  level. 

7.2  A  generic  specification  for  a  secure  resource  manager 

To  provide  a  general  tool  for  the  rapid  prototyping  of  secure  systems,  we  have  developed  a  general 
specification  for  a  secure  resource  manager.  To  illustrate  its  usefulness,  we  will  show  in  detail  how 
it  specializes  to  a  specification  of  the  Millen  operating  system,  and  describe  how  the  same  process 
could  be  applied  to  obtain  specifications  of  arbitrary  complexity. 

The  specification  method  we  use  is  that  of  final  algebra  specifications,  as  in  [Kam83],  [KJA83]. 
It  is  less  familiar  than  those  usually  encountered,  which  include,  for  example,  algebraic  specifica¬ 
tions,  and  specifications  given  by  defining  pre-  and  post-conditions  on  operations.  Therefore,  before 
giving  details  of  the  general  specification  and  its  specializations,  we  will  review  the  method  itself. 

7.2.1  Writing  final  algebra  specifications:  the  methodology 

Despite  its  name,  the  final  algebra  specification  method  is  not  what  is  generally  considered  to  be  an 
algebraic  method;  rather,  it  is  operational.  It  represents  elements,  essentially,  by  their  observable 
behavior.  Thus,  a  set  S  of  objects  of  sort  Elt  is  represented  by  a  map  from  the  carrier  of  Elt  to 
Bool;  this  map  determines  for  each  c  of  sort  Elt  whether  it  is  a  member  of  S.  If  the  operation  for 
observing  membership  is  named  isin,  then  the  map  corresponding  to  S  is  the  same  as  the  map  on 
elements  e  of  Elt  obtained  by  holding  S  constant  in  the  expression  isin(S,  e). 

fri  general,  an  element  of  an  abstractly  specified  sort  s  will  be  represented  by  a  tuple  of  maps 
(some  of  which  may  be  0-ary,  and  hence  *^aps”  only  by  courtesy).  Each  element  of  the  tuple  will 
correspond  to  an  operation  on  elements  of  sort  s  in  analogy  to  the  way  a  map  from  Elt  to  Bool 
corresponds  to  isin:  it  is  obtained  by  holding  the  element  of  sort  s  constant  while  letting  the  other 


156 


arguments  of  the  operation  vary.  The  operations  corresponding  to  tuple  components  of  elements 
of  sort  s  form  the  distinguishing  set  for  the  sort  s.  Thus,  the  distinguishing  set  of  the  sort  SetofElt 
consists  of  the  single  operation  isin. 

To  give  a  final  algebra  specification  of  ;  i  aostract  data  type,  one  must  first  determine  the 
operations  in  its  distinguishing  set.  Any  chuce  of  distinguishing  set  operators  leads  to  a  repre¬ 
sentation  of  elements  of  the  specified  sort  a^  elements  of  a  product  space;  this  representation  then 
permits  one  to  define  the  value  returned  by  an  operation  as  a  tuple  whenever  that  value  is  of  the 
specified  sort. 

There  is  no  fixed  recipe  for  finding  the  distinguishing  set,  but  there  are  some  hueristics.  In 
some  cases,  what  certain  components  of  this  product  space  must  be  is  clear.  For  example,  it  was 
clear  to  us  in  writing  our  generic  specification  that  any  SRM  (secure  resource  manager)  must  have, 
among  other  things,  a  State  component,  a  Scheduler  component,  and  a  SecPol  (security  policy) 
component.  When  this  happens,  it  is  dear  that  there  will  be  corresponding  distinguishing  set 
operations  that  yield  these  components.  In  the  case  of  an  SRM,  we  have  chosen  to  call  them 
stateofSRM,  schedofSRM,  and  polofSRM.  In  other  cases,  one  thinks  in  the  other  direction, 
and  starts  from  the  operations  to  get  the  product  space  representation.  A  typical  example  of  this 
is  an  abstract  sort  StackofElt,  in  which  one  realises  that  two  stacks  behave  the  same  if  one  gets  the 
same  things  by  reading  their  top  and  by  popping  them.  This  leads  to  a  (recursive)  representation 
of  StackofElt  as  a  product  Elt  x  StackofElt. 

As  we  have  indicated,  once  one  has  determined  the  tuple  representation  of  elements  of  the  sort 
being  specified,  one  can  then  define  certain  of  the  operations  that  return  values  of  this  sort  —  the 
constructor  operations  —  by  giving  their  results  as  tuples.  All  other  operations  must  be  defined 
in  terms  of  these  constructors,  the  distinguishing  set  operations,  and  the  visible  operations  from 
other  data  type  specifications,  without  the  use  of  tuples.  A  corollary  of  this  requirement  is  that 
tuples  can  be  used  to  express  elements  of  any  sort  only  inside  the  specification  of  that  sort. 

We  finish  this  subsection  with  a  brief  description  of  the  notation  and  conventions  used  in  our 
specifications;  these  are  as  in  the  FASE  system  as  described  in  [KJA83] 

Each  specification  begins  with  the  name  of  the  sort  being  specified,  followed  by  a  declaration 
of  operations  and  arities;  this  is  called  the  signature  section.  Any  operations  in  the  AUXILIARY 
OPERATIONS  section  are  available  only  inside  the  given  specification;  all  other  operations  are 
visible  operations,  and  may  be  used  by  programs  (including  other  specifications).  Following  the 
signature  section  is  the  list  of  those  declared  operations  that  constitute  the  distinguishing  set. 

Distinguishing  set  operations  do  not  require  explicit  definitions.  To  compute  the  application  of 
such  an  operation  to  a  list  of  arguments,  one  extracts  the  (unique)  argument  of  the  specified  sort, 
and  applies  the  corresponding  function  in  its  tuple  to  the  remaining  arguments  (a  trivial  application 
if  the  tuple  function  is  0-ary).  All  other  operations,  however,  require  definitions.  Tuples  in  these 
definitions  are  indicated  by  square  brackets,  their  elements  separated  by  commas.  0-axy  functions 
inside  tuples  are  simply  given  as  expressions.  For  functions  with  arguments,  the  notation  *‘<a,  b> 
|->  ..."  can  be  read  as  “A  a,b.  •  • 

With  regard  to  error  values,  there  is  an  error  value  of  each  sort,  together  with  a  hidden 
element  of  the  distinguishing  set  that  detects  it:  thus,  there  is  an  errSRM  and  an  iserrSRM, 
etc..  Function  definitions  are  strict  with  respect  to  errors.  Occasionally,  the  specifications  will 
include  definitions  of  the  form  uerrType(opType(sirg8))  ■>  •  •  •;  these  are  translated  as  a  prefix 
to  the  definition  of  opType  which,  when  satisfied,  causes  opType  to  return  an  error. 

The  following  notation  is  used  for  Boolean  operations:  is  used  for  and,  "I"  for  or, 

for  not,  and  **=’’  for  eqTypc  for  an  appropriate  choice  of  Type;  these  have  the  usual  precedences. 
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Note  that  in  the  caae  of  =,  except  for  a  primitive  tort  Type,  it  i*  not  required  that  eqType  be  a 
true  equality  relation,  but  only  that  it  be  explicitly  defined  and  have  the  appropriate  arity  (except 
that  the  system  forces  eqType  to  correctly  detect  equality  to  errType). 

7.2.2  Structure  of  the  generic  SUM  specification 

For  us,  the  term  "secure  resource  manager”  (abbreviated  SRM)  includes  practically  any  operating 
system.  In  our  attempt  to  construct  a  generic  specification  for  an  SRM,  we  wished  to  create  a 
template  which  could  be  elaborated  into  specifications  of  many  particular  systems.  We  at  first 
envisioned  that  such  a  template  would  consist  of  certain  fixed,  unchanging  specifications,  with 
subsorts  being  allowed  variable  specifications  whose  details  would  depend  on  a  pven  application. 
Instead,  it  became  clear  to  us  that  the  spedfied  sorts  in  the  template  would  fall  into  three  categories. 

We  win  caU  specifications  in  the  first  category  "fixed.”  These  are  essentiaUy  what  we  originany 
envisioned  as  fixed,  but  to  make  spedalisation  to  an  application  more  convenient,  we  have  loosened 
the  requirement  to  permit  addition  of  operations  derived  from  other  operations  in  the  (combined) 
specification.  For  instance,  our  Mifien  example  has  an  added  derived  operation  updateobjState 
in  the  specification  of  State.  In  such  specifications,  the  reachable  carrier  of  the  specified  sort  is 
fixed  relative  to  those  of  the  sorts  in  its  representation.  Hence,  any  properties  proved  from  the 
general  specification  about  all  reachable  elements  of  the  specified  sort,  say  by  structural  induction, 
will  hold  in  any  application. 

The  second  category  contains  what  we  will  call  "fixed  representation”  specifications.  These  will 
specify  a  sort  of  fixed  name,  and  will  have  a  fixed  list  of  distinguishing  set  operations  of  fixed  arity. 
As  a  result,  the  representation  of  the  specified  sort  will  be  fixed  relative  to  the  sorts  involved  in  its 
representation.  In  general,  such  abstract  types  will  have  a  fixed  set  of  constants  whose  definitions 
are  independent  of  the  application,  and  sometimes,  other  operations  with  fixed  definitions.  Any 
properties  that  can  be  proved  without  structural  induction  about  the  elements  of  such  a  sort  based 
on  provable  properties  of  the  sorts  in  its  representation  will  still  hold  in  any  application.  Two  sorts 
in  our  template  which  have  fixed  representation  specifications  are  SRMop  and  SecPol.  SBMop  has 
a  fixed  null  operation  NOop,  and  a  fixed  "equality”  operation  eqSRMop  (which  is  not  a  true 
equality,  but  behaves  like  one  in  this  and  any  jq)plication  in  which  no  two  operations  can  have  the 
same  name).  SecPol  has  default  polides  noPol  and  recalcitrantPol. 

The  third  category  of  specifications  contains  those  having  a  fixed  subsignature.  In  fixed  sub- 
signature  spedficatioiu,  at  the  very  least,  there  must  be  a  sort  of  the  same  name  as  the  specified 
sort.  In  general,  certain  operations  of  a  certain  arity  also  must  be  present.  Other  than  arity,  there 
is  no  restriction  on  how  the  operations  are  defined.  Such  specifications  correspond  to  the  parameter 
part  of  parameterixed  specifications  which  occur  in  other  specification  methods  (e.g.,  that  of  OBJ 
[GM82a],  [GM84b]).  Two  of  the  sorts  with  such  specifications  in  our  template  are  Object  and 
Request.  Object  has  a  fixed  operation  eqObject,  which  has  fixed  arity.  Request  has  the  fixed 
operations  opoiRequest  and  sirgsofRequest,  also  with  fixed  arities. 

In  any  application,  there  will  be  subsidiary  data  tyi>e  specifications,  which  we  simply  refer  to 
as  application  specific.  The  sorts  spedfied  need  not  appear  in  all  applications,  fluently,  they 
are  required  in  order  to  define  sorts  needed  in  the  representation  of  sorts  of  fixed  subsignature,  or, 
possibly,  of  other  application  specific  sorts.  Among  the  application  specific  sorts  present  in  our 
MiRen  example  is  Content;  it  exists  only  to  define  part  of  the  representation  of  sort  Object. 

Instead  of  giving  the  SRM  template  specification  in  isolation,  we  will  show  its  completion  for 
the  Millen  example,  and  indicate  which  parts  belong  the  the  template.  Table  1  gives  a  complete  list 
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of  the  sort  specifications  in  oni  Millen  specification,  together  with  an  indication  of  the  kind  of  the 
specification  (1  =  fixed,  2  =  fixed  representation,  3  =  fixed  subsignature,  4  =  application  specific) 
and  the  abstract  representation  of  each  sort.  Note  that  the  alternate  representations  mentioned  in 
the  table  as  being  the  “real”  representations  of  certain  sorts  show  the  structure  of  the  reachable 
part  of  the  sorts. 

As  we  have  indicated,  the  general  template  consists  of  parts  of  those  specifications  of  kinds  1, 2, 
and  3.  In  table  2,  we  indicate  for  each  of  these  specifications  those  operations  in  the  Millen  example 
that  are  present  in  the  template.  The  degree  to  which  they  are  “present”  is  determined  as  described 
earlier  by  the  specification  kind.  For  kind  2  specifications,  we  don’t  mention  the  distinguishing  set 
operations,  since  they  must  always  be  present  in  the  template. 

As  a  further  aid  to  understanding  the  template  specification,  figure  6.2.2  gives  a  graphic  rep¬ 
resentation  of  the  structures  of  sorts  in  the  template  having  kind  1  and  kind  2  specifications.  The 
sort  at  each  node  in  the  tree  is  represented  abstractly  by  the  sorts  of  its  children. 

As  indicated  in  table  1,  the  representations  of  ObjectSet  and  ProcessSet  are  different  in  the 
Millen  specification  from  those  in  the  generic  specification.  In  general,  for  the  purposes  of  rapid 
prototyping,  it  is  sometimes  convenient  to  replace  a  spedfication  by  an  implementation,  for  a 
number  of  reasons.  In  our  Millen  example,  we  have  actually  given  implementations  of  ObjectSet 
and  ProcessSet,  rather  than  their  ideal  specifications  (in  which  sets  would  be  represented  as  maps 
to  Bool).  These  ideal  specifications  can,  in  faict,  be  given  in  the  EASE  language,  but  would  require 
the  use  of  quantifiers  (the  operations  findinObjectSet  and  flndinProcessSet  would  use  the 
quantifier  “some”  —  the  existential  operator  that  returns  an  instance).  While  many  quantified 
expressions  can,  in  fact,  be  executed  in  EASE  [JK86],  this  execution  tends  to  be  slow.  Moreover, 
for  printing  all  members  of  sm  element  of  a  “set”  data  type,  as  one  frequently  wants  to  do  in 
an  interactive  driver  for  a  prototype,  it  is  much  more  convenient  to  represent  the  set  as  a  list. 
Thus,  we  have  chosen  to  do  so  in  the  Millen  specification.  Of  course,  there  is,  strictly  speaking,  a 
proof  obligation  attached  —  one  must  verify  that  the  implementation  is  correct.  In  this  case,  the 
implementation  is  actually  partial  —  one  cannot  create  an  arbitrary  set  of  Objects,  for  example, 
but  only  one  in  which  no  two  Objects  have  the  same  Objectid.  However,  one  can  show  that  no 
SRMop  causes  one  to  attempt  to  create  a  disallowed  ObjectSet,  provided  one  starts  with  a  State 
having  a  permissible  one.  Thus,  in  the  context  in  which  the  Millen  ObjectSet  specification  will  be 
used,  it  can  be  considered  an  implementation  of  the  generic  ObjectSet  ([KA84],  [Arc88]). 

As  a  matter  of  fact,  the  notion  of  partial  implementation  crops  up  frequently  in  the  context 
of  specializing  the  generic  template  to  a  specific  example.  One  place,  as  we  have  indicated  earlier, 
is  the  specification  of  “equality”  operators  that  are  not  true  equality  operators,  but  are  sufficient 
in  context.  Another  place  is  in  the  use  of  a  History  component  in  the  generic  SRM.  It  is  there  to 
facilitate  detection  of  information  flow  in  cases  where  this  cannot  be  observed  simply  by  looking 
at  the  rest  of  the  State.  Provided  that  the  History  is  never  used  to  affect  operations  (i.e.,  in  the 
definition  of  any  SBMop),  but  only  used  to  observe  the  system,  there  is  no  reason  to  implement  it 
in  implementing  a  system  whose  specification  one  has  proved  secure. 

7.2.8  Specializing  the  template  SRM  specification 

We  believe  that  the  usefulness  of  the  template  SBM  specification  lies  in  how  it  organizes  one’s 
thinking  about  the  workings  of  an  (almost)  arbitrary  secure  system  by  factoring  the  system  into 
its  components  that  play  conceptually  different  roles,  and  also  in  relieving  one  of  having  to  specify 
certain  high-level  operations.  Some  of  these  components  (e.g.,  the  Scheduler)  will  play  more  im- 
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SORT  KIND  REPRESENTATION 


SRM 

1 

SRMopSet  X  State  x  Scheduler  x  Interp  x  SecPol 

State 

1 

ObjectSet  x  ProcessSet  x  RequestList  x  History 

SRMopSet 

1 

SRMop  -»  Bool 

SRMop 

2 

Symbol  x  (State  x  ArgList  -»  State) 

Scheduler 

2 

(State  -»  Request)  x  (State  -*  RequestList) 

Ihterp 

2 

Request  -»  Request 

SecPol 

2 

(State  X  Request  Bool)  x  (State  x  Request  Request) 

Object  Set 

1 

Object  X  ObjectSet 
[  in  genetic  template,  Object  Bool  ] 

ObjectPred 

2 

Object  -»  Bool 

Objectid 

3 

Symbol  x  Symbol  x  Int  x  Processid 
[really  {’X}  +  Int  +  Int  x  Processid] 

Object 

3 

Objectid  X  Content  x  Level  x  Int  x  Int 

ProcessSet 

1 

Process  x  ProcessSet 
[  in  generic  template.  Process  — »  Bool  ] 

ProcessPred 

2 

Process  — »  Bool 

Proceuld 

3 

Symbol  x  Int 

[really  {’System}  +  Int)] 

Process 

3 

Processid  x  Bool  x  Level  x  [Int  -♦  Object]  x  [Int  -*  Object] 

ReqaestList 

1 

Request  x  RequestList 

Request 

3 

SRMop  X  ArgList  x  Processid 

History 

3 

State  X  RequestList 

ArgList 

1 

Arg  X  ArgList 

Arg 

3 

Object  X  Process  x  Int 
[really  Object  +  Process  +  Int] 

Content 

4 

Symbol  x  Int  x  (Int  Int) 

(really  Int  +  (Int  -» Int)] 

Level 

4 

Bool  X  Symb^ 

[really  {’syshi}  +  Symbol] 

RegAssn 

4 

Int  bt 

CompnteFn 

4 

Symbol  x  (RegAssn  -» Int) 

Tkble  1:  Milleii  ipcdficAtion  overview 
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SORT  KIND  GENERIC  OPERATIONS 

SRM 

1  (aU) 

SRMopSet 

1  (all  but  mitreSRMopSet) 

SRMop 

2  eqSRMop  ,  NOop 

State 

1  (all  but  updateobjState  ) 

Scheduler 

2  null-  and  trivScheduler 

Interp 

2  trivinterp 

SecPol 

2  no-  and  recsdcitrantPol 

ObjectSet 

1  (all) 

ObjectPred 

2  trivObjectPred 

Objectid 

3  eqObjectId  and  precedesObjectId 

Object 

3  idofObject 

ProcessSet 

1  (all) 

ProcessPred 

2  trivProcessPred 

Ptocessid 

3  eqProcessId  and  precadesProcessId 

Process 

3  idofProcess 

RequestList 

1  (all) 

Request 

3  opof-,  stfgsof-,  procidof-,  and  nuURequest 

History 

3  init-  and  appendHistory 

ArgList 

1  (all) 

Arg 

3  objidof-,  procidof-  ,  objidto-  ,  and  procidtoArg 

All  diatingaisliing  set  operations  of  kind  2  and  kind  1  specifications  are  also  generic. 
For  operations  in  kind  3  specifications,  only  the  aiity  is  generic. 

Ikble  2:  Generic  template 
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SRM 


ObjectPred - (Object  -  Bool) 

ProceiePred  — (Proceii  -*  Bool) 

cow  f—  Symbol 

****  ‘-(State  X  Argliet  -  State) 


rProceuSet  ■ 
Ob  jectSet  - 


f— State - 


■RequestList• 


^Hietory 

•SRMopSet - (SRMop  -*  Bool) 

* — (State  -♦  ReqaeitLut) 
■Interp - (Request  -♦  Bequest) 


^SecPol- 


-(State  X  Request  -*  Bool) 
-(State  X  Request  Request 


c 


(Process  -*  Bool) 

(Object  -►  Bool) 

Request 
Request  List 


Figure  1:  Overview  of  the  SRM  template  specification 
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portant  roles  in  some  systems  than  others,  but  for  any  relatively  complex  system,  most  of  them 
will  be  non- trivial.  The  template  has  one  further  advantage:  when  it  is  completed  (and  in  many 
cases,  only  partially  completed),  it  can  be  used  as  a  rapid  prototype  of  a  system  (or  part  of  it). 

Obtaining  the  Millen  specification:  As  a  concrete  illustration  of  how  the  template  SRM  spec¬ 
ification  can  be  useful,  we  will  describe  here  the  major  decisions  we  needed  to  make  in  specializing 
it  to  a  specification  of  the  Millen  system.  In  the  process  of  specialization,  a  number  of  omissions  in 
the  description  of  the  Millen  system  in  [Mil79]  became  clear,  and  we  had  to  make  some  decisions 
about  how  to  handle  them.  We  tried  to  make  these  decisions  so  as  to  allow  as  much  flexibility  as 
possible  in  the  system  objects  one  might  wish  to  create  for  testing  purposes. 

In  specializing  the  template,  one  first  has  to  make  decisions  about  how  to  complete  the  kind  2 
specifications.  We  will  take  these  in  order. 

The  first  such  specification  we  encounter  is  SBMop,  which  determines  what  can  be  in  an  SR- 
MopSet.  Here,  we  soon  discovered  that  the  list  of  operations  in  [Mil79]  needed  to  be  expanded.  For 
example,  a  user,  not  being  privileged,  cannot  directly  execute  certain  commands  such  as  Swap  and 
Purge  (SWAP  and  PURGE  in  [Mil79]).  The  user  is  also  unable  to  do  a  Get  (GET,  in  [Mil79]), 
not  having  access  to  information  about  free  memory  blocks.  Thus  we  have  added  user  opera¬ 
tions  uSleep,  uRelease,  and  uGet  which,  in  effect,  ask  the  system  to  request  the  corresponding 
privileged  operations.  We  similarly  decided  that  the  privileged  operation  Raise  will  normally  be 
invoked  as  the  indirect  result  of  certain  user  calls  to  uGet,  and  that  the  privileged  operations 
ReadX  and  WriteX  (READ  and  WRITE  the  X  register  in  [Mil79]  —  created  there  to  illustrate  a 
possible  way  to  introduce  a  security  flaw,  which  we  wanted  to  be  able  to  exhibit)  similarly  required 
corresponding  user  calls  to  uReadX  and  uWriteX,  respectively.  There  are  also  problems  with 
the  nominally  purely  user  operations  uFetch,  uStore,  and  uCompute  (FETCH,  STORE,  and 
COMPVTEk  in  {Mil79])  since  a  process  would  have  to  pass  itself  (or  its  name)  as  an  argument  so 
that  the  correct  memory  block  and  registers  to  reference  can  be  determined.  Thus  we  also  added 
correspr  nding  system  (although  not  privileged)  operations  Fetch,  Store,  and  Compute. 

Our  template  specification  is  structured  to  permit  the  definitions  of  operations  to  be  factored 
into  what  the  operations  do,  and  the  pre-conditions  under  which  the  operations  will  be  allowed.  In 
our  Millen  example,  we  isolate  the  pre-conditions  into  the  SecPol  factor  of  the  SRM,  particularly 
since  their  enforcement  is  the  system’s  attempt  to  enforce  the  ’Hrue”  security  policy.  Thus,  our 
operation  definitions  in  the  SRMop  specification  are  free  of  the  clutter  of  the  pre-conditions. 

The  actual  definitions  of  the  operations  force  a  number  of  implementation  decisions  concerning 
what  will  be  the  elements  of  Arg  and  what  some  of  the  operations  on  Objects  and  Processes  must 
be.  E  g  there  must  be  Int  and  Objectid  arguments,  and  there  must  be  an  operation  by  which  to 
observe  :he  Content  of  an  Object. 

The  next  kind  2  specifications  we  encounter  are  ObjectPred  and  ProcessPred.  We  see  that  we 
cannot  add  constructors  to  these  data  types  without  knowing  more  about  the  structure  of  Objects 
and  Pro<.esses.  Since  the  Millen  specification  refers  to  Processes  and  memory  blocks  (which  will 
be  one  iL^nd  of  Object)  by  number,  end  registers  (another  kind  of  Object)  by  name  or  number,  we 
decide  that  both  Processes  and  Objects  must  have  Ids,  and  that  there  must  be  predicates  to  decide 
when  a  given  Object  or  Process  has  a  given  Id.  Thus  we  are  also  led  to  create  additional  data  types 
called  Objectid  and  Processid,  having  equality  operators.  Having  done  this,  we  can  now  defined 
the  desired  predicates  that  test  equality  of  an  Id  to  a  given  one. 

We  next  encounter  the  components  of  the  State.  The  only  component  not  of  kind  1  is  the 
History  (kind  3).  Though  we  are  mainly  discussing  only  kind  2  specifications,  it  is  worth  looking 
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more  closely  at  History  in  order  to  luderstand  the  role  it  plays.  In  general,  a  History  object 
could  be  less  detailed  than  we  make  it;  since  it  is  there  for  flow-detection  purposes,  it  is  enough  to 
record  whatever  information  is  needed  for  this  purpose.  We  have  chosen  to  keep  essentially  all  the 
information  needed  to  reconstruct  all  changes  of  system  State.  Thus,  a  History  is  a  State  and  a 
RequestList;  initHistory  saves  the  initial  State,  and  appendHistory  is  used  to  successively  save 
requests. 

There  being  no  explicit  mention  of  scheduling  in  [Mil79],  we  have  taken  the  Scheduler  to  be 
trivScheduler. 

In  general,  we  see  the  Interp  component  of  an  SRM  —  the  Request  interpreter  —  to  be  a 
mechanism  by  which  the  system  can  trap  user  requests  and  interpret  them  in  terms  of  commands 
only  known  to  the  system.  This  seems  to  us  to  be  the  natural  way  to  aQow  for  operations  such 
as  TBAP  [Mil79].  The  specific  element  of  s<»t  Interp  that  needs  to  be  included  in  any  MilVn 
system  is  mitrahiterp,  which  changes  user  Bequests  into  lists  of  Requests  involving  ‘Eternal” 
operations;  thus,  a  user  nGet  request  becomes  one  of  the  sequences  <Get>  or  <Raise,  Get>  of 
system  requests. 

In  any  SRM,  the  SeePol  component  will  be  the  “effective  security  policy”  —  actually,  the  filter 
on  Requests  that  attempts  to  enforce  the  true  seciui^  policy  —  of  the  system.  In  operation,  it 
tests  a  Request  for  whether  the  pre-conditions  associated  with  its  SRMop  are  satisfied.  In  the 
Millen  example,  these  pre-conditions  actually  simply  implement  an  access  policy;  in  general,  they 
could  make  much  more  complex  tests  that  might  even  examine  the  History  component  of  the  State. 
However,  the  way  we  have  structured  mitreSeePol  is  typical  of  the  way  we  would  expect  the  SeePol 
of  any  SRM  to  be  structured:  separate  SecPols  for  the  operations  are  combined  into  the  overall 
SeePol.  The  tests  made  by  the  SeePol  on  operations  force  some  further  decisions.  For  example,  the 
fact  that  the  SeePol  wants  to  know  the  Level  of  the  Process  requesting  certain  operations  means 
that  such  information  must  be  obtainable  from  a  Request.  We  have  chosen  to  give  each  Request 
a  Processid  component,  although  it  would  be  sufficient  to  just  use  the  Level  of  the  corresponding 
Process.  Other  decisions  forced  by  the  definition  of  SeePol  are  that  each  Object  must  have  a  Level, 
and  Int  representing  its  access  count,  and  so  on. 

Obtaining  a  specification  of  your  pet  system:  The  procedure  we  used  above  for  the  Millen 
example  can  be  followed  to  yield  a  specification  of  almost  any  system.  Basically,  one  completes 
the  kind  2  specifications;  in  the  process,  one  finds  out  the  structure  of  the  sorts  having  kind  3 
specifications,  and  the  operations  needed  in  these  specifications.  In  the  process  of  elaborating  the 
kind  3  specifications,  one  creates  the  needed  kind  4  sjwcifications. 

More  particularly,  one  starts  by  determining  the  SRMops  —  the  operations  provided  in  the 
system.  Any  restrictions  on  the  pennissiblity  of  these  operations  can  be  factored  out  and  made 
part  of  the  SeePol.  Which  constructors  to  add  to  ObjeetPred  and  ProceuPred  depend  mainly  on 
the  needs  of  the  SRMops,  since  these  operations  are  the  ones  that  ultimately  select  Objects  or 
Processes  in  order  to  change  (or,  in  our  applicative  system,  replace)  them.  There  may  be  cases, 
however,  in  which  SeePol,  for  example,  needs  particular  ObjeetPreds  or  ProcessPreds.  The  basic 
properties  of  an  Object  or  Process  can  usually  be  determined  from  the  high-level  description  of  the 
system,  ^irther  details  that  distinguish  individual  Objects  or  Processes  are  determined  by  what 
various  SRMops  do,  what  the  SeePol  needs  to  test  for,  and  so  on.  The  needs  of  the  Scheduler 
and  the  SeePol,  primarily,  determine  what,  besides  an  SRMop  and  an  ArgList,  distinguishes  one 
Request  from  another.  In  the  Millen  example,  a  Request  had  an  associated  Processid;  in  systems 
with  a  nontrivial  Scheduler,  Requests  may  need  to  have  an  associated  priority  instead,  or  as  well. 
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Whether  there  will  be  a  nontrivial  History  component  in  the  State  depends  on  what  information 
flows  one  wants  to  test  for,  and  how  much  information  about  the  previous  states  of  the  system  one 
needs  in  order  to  do  so. 

7.3  Running  the  specification:  the  Millen  example 

As  mentioned  in  the  previous  section,  we  attempted  to  make  our  Millen  specification  as  flexible  as 
possible;  the  reason  for  this  is  that  one  can  then  initialize  the  system  to  any  permissible  configuration 
desired:  any  number  of  user  processes  (numbered  starting  from  0),  any  number  of  registers  for  any 
given  user  process,  any  number  of  memory  blocks,  etc..  Having  done  this,  we  assume  that  the 
system  will  be  initialized  in  a  permissible  configuration;  we  also  assume  that  the  driver  accepts 
requests  only  if  they  could  occur  in  the  current  state  of  the  system.  These  conditions  could  be 
enforced  inside  the  specification,  but  it  would  be  cumbersome  to  do  so,  and  we  have  chosen  not  to. 

In  the  case  of  the  Millen  example,  the  SRMopSet  of  the  initial  configuration  must  be  mitreS- 
RMopSet.  Also,  the  State  of  an  initial  configuration  will  have  only  one  swapped-in  Process,  and 
no  memory  block  Objects  that  are  referenced  by  more  than  one  Process;  moreover,  its  ProcessSet 
must  consist  of  the  systemProcess  and  zero  or  more  user  Processes  with  Processids  numbered 
consecutively  from  0.  Finally,  the  Scheduler  of  any  initial  configuration  must  be  trivScheduler, 
its  Interp  must  be  mitreinterp,  and  its  SecPol  must  be  mitreSecPol. 

Once  an  initial  configuration  is  assigned  to  a  Lisp  variable,  updates  to  this  configuration  must 
be  done  by  stepSRM,  which  will  never  violate  the  conventions  of  the  system,  and  newreqSRM. 
The  driver  should  accept  a  new  Request  only  if  it  comes  from  a  Process  of  which  inofProcess  is 
true  (meaning  the  Process  is  swapped  in). 

Thus,  to  complete  the  rapid  prototype  of  the  Millen  system  one  should  write  a  driver  that 
1)  creates  a  permissible  initial  configuration  of  the  system  upon  reading  input  that  controls  the 
variables  in  such  a  configuration  (such  as  how  many  Processes  there  are,  what  memory  block 
Objects  of  what  sizes  there  are,  etc.),  2)  takes  as  input  instructions  either  to  call  stepSRM  or  to 
call  newreqSRM  with  a  new  Request,  and  3)  checks  that  incoming  Requests  could  in  fact  arise  at 
the  point  they  are  given  as  input.  As  we  will  explain  in  the  next  section,  the  EASE  system  provides 
a  means  to  make  the  input  instructions  convenient  to  give  interactively  without  the  use  of  the  long 
function  names  appearing  in  the  specification,  and  makes  it  convenient  to  write  a  driver  for  the 
system  in  Lisp. 

Although  we  have  not  yet  written  a  driver  for  the  Millen  system,  we  have  written  drivers  for 
a  number  of  other  EASE  specifications,  and  anticipate  no  difficulties  in  doing  so. 

7.4  Advantages  of  the  FASE  system 

The  FASE  system  [KJA83]  is  a  system  for  executing  final  algebra  specifications  [Kam83]  of  abstract 
data  types.  We  find  its  use  convenient  for  several  reasons.  Perhaps  the  most  important  reason  is  that 
the  specifications  are  executable  whenever  they  do  not  involve  quantifiers.  Even  some  specifications 
with  quantifiers  are  executable,  and  the  system  is  able  to  identify  a  class  of  such  spedficatioiu  which 
it  guarantees  it  can  execute  (although,  for  efficiency  reasons,  it  is  best  to  avoid  quantification  in  a 
rapid  prototype). 

There  are,  of  course,  other  systems  for  executing  specifications,  such  as  OBJ  and  Afl^rm 
[GHM78].  These  mostly  involve  algebraic  (equational)  specifications.  While  such  specifications 
are  sometimes  straightforward  to  write,  knowing  when  one  has  enough  equations  (or  so  many  as 
to  lead  to  inconsistency)  can  be  a  problem.  By  contrast,  we  find  final  algebra  specifications  to 
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be  among  the  easiest  specificatioas  to  write.  One  does  not  have  the  problem  of  proving  sufficient 
completeness  and  consistency  of  equations.  Once  one  has  determined  the  abstract  representations 
as  tuples  of  elements  of  various  sorts,  the  definitions  of  their  associated  operations  are  usually 
straightforward  to  derive  from  verbal  descriptioiu. 

In  addition,  the  FASE  system  is  integrated  with  Lisp,  so  that  one  can  easily  write  Lisp  drivers 
to  exercise,  and  hence  test,  one’s  specifications  interactively.  One  can  easily  incorporate  into  a 
driver  print  routines  that  call  operations  from  the  specification  in  order  to  display,  for  example,  a 
system  state  represented  in  some  convenient  fashion  by  its  observable  behavior. 

Specification  and  testing  are  further  much  facilitated  by  a  provision  for  almost  arbitrary  user- 
defined  syntax.  With  an  appropriate  grammar,  one  can  easily  handle  the  formation  of  sets  and 
sequences,  as  wdl  as  coercions,  and  avoid  typing  in  lengthy  (though  possibly,  as  in  our  example, 
descriptive)  function  names.  User  expressions  axe  delimited  in  Lisp  by  exclamation  points,  and  in 
specifications  by  underscores.  Thus,  in  our  Millen  example,  we  can  provide  a  grammar  that  will 
allow  us  to  say  at  the  lisp  level: 

.'user  0  calls  uEeadX  on  2,  5  in  M! 
to  abbreviate 

(nevreqSRM  (mkRequest  (uReadZ) 

(appendArgLiat  (inttoArg  5) 

(appendArgLiat  (inttoArg  2)  nilArgLiat}} 
(nkuaerProceaald  0}) 

M) 

(note  that  M  in  both  the  above  can  be  a  Lisp  variable  whose  value  is  of  sort  SRM).  While  overloading 
of  operators  in  the  specifications  per  se  is  not  allowed,  it  is  feasible  to  a  great  extent  in  the  grammars, 
since  the  parser  is  able  to  do  type-checking  of  aU  but  variables. 

7.5  The  PLANNER 

This  subsection  discusses  an  approach  to  formal  testing  of  an  operating  system  with  respect  to 
a  security  policy.  The  goal  of  the  work  is  as  follows:  Given  specifications  for  the  operations  of 
an  operating  system,  determine  a  sequence  of  operations  that  effect  a  disallowed  information  flow 
between  a  pair  of  processes,  assuming  that  such  a  flow  exists. 

This  concept  is  implemented  in  a  prototype  system  called  the  PLANNER;  it  is  implemented 
in  Prolog,  but  uses  its  own  searching  code  to  make  the  search  more  informed  that  the  basic  Prolog 
resolution  method.  It  is  based  on  an  extension  of  classical  AI  planning  methods  [NilSO]. 

T.5.1  Detecting  flows 

Planning  (of  actions)  is  concerned  with  the  automatic  derivation  of  a  sequence  of  operations  (called 
the  plan)  that  achieve  a  goaL  In  flassiral  planning,  the  goal  is  expressed  in  terms  of  two  states:  an 
initial  state  and  a  final  state,  and  the  sequence  of  operations  is  to  achieve  the  final  state  given  the 
initial  state.  Planning  has  been  used  to  derive  plans  for  moving  robot  vehicles  so  as  to  achieve  a 
goal  such  as  ^refueling  a  tank.” 

The  basic  approach  to  planning  involves  searching  combined  with  unification.  The  searching 
can  be  forward  driven,  backward  driven,  or  mixed.  The  backward  approach  is  as  follows.  The  goal 
and  initial  states  are  described  in  terms  of  predicates  on  constants  and  variables.  The  operations 
are  specified  in  terms  of  preconditions  and  postconditions,  each  expressed  in  terms  of  variables  and 
constants.  Variables  can  be  bound  during  the  planning  process. 
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If  the  goal  state  unifies  with  the  initial  state,  the  plan  is  complete.  The  collection  of  operations 
is  scanned  to  locate  an  operation  with  a  postcondition  that  unifies  with  the  goal  state.  This 
operation  might  have  preconditions;  for  simplicity,  assume  there  is  only  a  single  precondition.  The 
variables  of  the  precondition  might  be  bound  to  values  as  a  result  of  the  unification  of  the  goal  state 
with  the  postconditions.  Then  the  postcondition,  with  the  variables  appropriately  bound,  becomes 
the  new  goal. 

Complications  arise  when  the  goal  is  a  conjunction  of  terms;  a  conjunction  of  terms  can  arise  at 
any  point  in  the  planning  process;  for  example,  when  an  operation  is  used  that  has  more  than  one 
precondition.  Significant  research  has  been  devoted  to  this  problem,  none  of  the  solutions  avoiding 
possible  long  and  fruitless  searches.  One  technique  is  as  follows.  When  encountering  a  conjunction 
of  goals,  pick  one  to  work  on;  it  might  be  possible  to  identify  the  most  difficult  of  the  goals  assuming 
a  measure  of  difficulty  is  available.  Identify  an  operation  with  a  postcondition  that  unifies  with 
this  selected  goal.  Then  the  other  goals  are  regressed  backwards  through  this  operation.  If  the 
regressed  goals  conflict  with  the  preconditions,  than  the  choice  of  operation  or  the  goal  selected  to 
pursue  was  flawed,  and  the  procedure  backtracks  to  select  a  different  operation  or  a  different  goal. 
The  planning  process  continues  until  the  collection  of  goals  unifies  with  the  initial  state. 

Our  security-based  PLANNER  is  similar,  but  introduces  some  new  concepts  to  cope  with 
information  flow. 

The  goal  state  expresses  an  insecure  flow,  and  is  based  on  the  concept  of  “interference”  of 
processes  in  an  operating  system.  The  concept  of  flow  and  of  a  a  model  “process”  is  wired-into  the 
PLANNER  to  reduce  the  search  space.  A  more  general  planner  would  take  an  arbitrary  security 
policy  and  model  of  processes,  but  at  the  expense  of  search  time. 

Assume  a  goal  state  in  which  process  Pi  is  running  and  has  read  access  to  a  collection  of 
renters;  it  is  through  these  registers  that  a  process  acquires  information.  Assume  an  initial  state 
in  which  Pi  is  also  running.  The  contents  of  a  register  in  the  initial  state  and  final  state  are  to  differ. 
In  order  to  exhibit  information  flow,  the  difference  is  to  be  caused  by  an  operation  by  a  process  Pj 
whose  security  level  is  not  less  than  or  equal  to  that  of  Pi',  for  simplicity  the  PLANNER  assumes  a 
category  model  of  security  levels:  processes  at  different  levels  are  forbidden  to  communicate  with 
each  other.  Still  working  backwards,  the  PLANNER  will  have  two  types  of  goals  to  achieve: 

1.  Goals  that  involve  information  flow  between  processes:  These  goals  are  achieved  by  two 
operations,  one  that  produces  a  change  in  state  (e.g.,  to  a  register)  and  the  other  that  causes 
a  swap  of  processes.  Assuming  no  single  operation  satisfies  both  of  these  needs,  the  final  plan 
must  contain  these  two  operations  but  not  necessarily  contiguously. 

2.  “Ordinary”  goals  as  faced  by  the  classical  planner.  These  goals  will  arise  from  preconditions 
of  operations  that  the  planner  conjectures  will  become  part  of  the  plan. 

These  concepts  are  discussed  in  the  next  section  with  reference  to  the  PLANNER  deriving  a 
plan  for  insecure  flow  in  the  Millen  operating  system. 

7.5.2  Detailed  description 

The  current  implementation  of  the  PLANNER  consists  of  a  collection  of  rules  written  in  Prolog. 
Prolog  was  selected  in  order  to  take  advantage  of  backtracking  and  resolution.  Use  of  backtracking 
provides  a  method  whereby  all  possible  plans  may  be  considered,  and  use  of  resolution  permits 
planning  variables  to  be  left  unbound  as  long  as  possible.  The  PLANNER  contains  four  types  of 
rules:  planning  rules,  difference  computation  rules,  operation  rules,  and  architecture  rules. 
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Planning  rules:  Planning  rules  are  used  to  manipulate  plans.  There  are  two  types;  those 

that  eliminate  “unnecessary”  goals,  and  those  that  select  the  subgoal  which  will  be  achieved  next. 
Unnecessary  goals  are  goals  that  have  already  been  achieved  (as  a  side  effect  of  solving  other  goals), 
or  goals  that  do  not  cause  any  real  change  in  state.  For  example,  the  system  may  have  two  goals: 
causing  user  A’s  register  i  (denoted  £(i4,i))  to  contain  value  X  (Goal  1),  and  causing  user  A  to 
become  the  currently  active  user  (Goal  2).  Suppose  that  in  the  initial  state,  user  B  is  active  and 
user  A  is  blocked,  and  that  only  active  processes  may  modify  their  registers.  Farther  suppose  that 
the  system  chooses  to  work  on  Goal  1  first,  and  achieves  it  via  the  following  plan: 

1.  Make  user  A  active  so  that  X  may  be  written  into  R{A,  i) 

2.  Write  X  into  J2( A,  t) 

Clearly,  Step  1  of  the  plan  also  achieves  Goal  2,  so  that  goal  may  be  eliininated  from  the  system. 
Step  1  and  Step  2  may  be  considered  subgoals  of  Goal  1. 

The  second  type  of  plantiing  rules  consists  of  those  rules  that  determine  which  goal  the  PLAN¬ 
NER  will  try  to  a^eve  first.  In  theory,  the  goals  are  achievable  in  any  order:  if  the  PLANNER 
determines  that  it  is  impossible  to  achieve  all  goals  at  some  point  in  the  computation,  then  it  back¬ 
tracks  and  tries  them  in  a  different  order.  However,  in  practice  this  does  not  always  work  with  the 
current  version  of  the  PLANNER,  since  it  does  not  recognize  infinite  loops  in  planning  sequences. 
The  PLANNER  may  attempt  to  achieve  a  sequence  of  goals  where  the  solution  to  the  first  goal 
“undoes”  the  solution  to  the  last  goal.  This  may  be  seen  clearly  in  the  following  example. 

Consider  a  system  containing  Goal  1  (described  earlier)  and  Goal  2':  make  user  B  active.  This 
time,  user  A  is  active  initially.  The  following  sequence  will  loop  infinitely: 

1.  Make  user  B  active  (to  achieve  Goal  2^). 

2.  Make  user  A  active  (to  achieve  Subgoal  1  of  Goal  1).  This,  however,  undoes  Goal  2'. 

3.  Make  user  B  active  (to  achieve  Goal  2') 


Both  subgoals  could  have  been  achieved  if  the  PLANNER  had  chosen  to  complete  both  of  Goal  I’s 
subgoals  before  attempting  to  achieve  Goal  2’.  In  order  to  avoid  this  type  of  looping,  the  current 
version  of  the  PLANNER  uses  two  heuristics:  complete  all  the  subgoals  of  a  goal  at  one  time,  and 
complete  the  most  complicated  goals  first  (these  are  the  goals  most  likely  to  undo  other  goals). 
The  complexity  of  a  rule  is  measured  by  counting  the  number  of  subgoals  it  contains.  These  two 
heuristics  are  not  sufficient  to  prevent  all  infinite  loops,  so  future  implementations  of  the  PLANNER 
are  expected  to  contain  some  form  of  loop  detection  and  escape.  Possible  methods  of  achieving  this 
are  discussed  in  the  conclusion. 

Difference  rule*:  The  PLANNER  operates  by  determining  the  differences  between  an  initial 
state  and  a  final  state,  and  then  attempting  to  eliminate  these  differences.  The  PLANNER  com¬ 
putes  differences  by  comparing  state  components  in  the  initial  and  final  states.  For  example,  if 
process  A’s  renter  R{A,i)  contained  the  value  X  in  the  initial  state  and  the  value  Y  in  the  final 
state,  then  the  PLANNER  would  add  a  register  difference  of  [[A,  i,  X],  [A,  i,  Y]]  to  the  current 
goal  list.  Every  state  component  has  its  own  collection  of  difference  rules,  since  these  depend  upon 
the  representation  of  that  component. 
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Operation  rules:  The  operation  rules  embody  the  semantics  of  system  operations.  Each 

operation  the  system  provides  is  described  in  terms  of  preconditions  and  postconditions.  For 
example,  it  was  mentioned  earlier  that  a  precondition  of  writing  into  a  given  process’  register  is 
the  requirement  that  the  process  be  currently  active.  A  postcondition  of  writing  the  value  X  into 
register  R  is  that  register  R  now  contains  the  value  X. 

Figure  2  is  a  high-level  description  of  the  Fetch  operation  defined  in  the  Millen  system.  Oper¬ 
ationally,  Fetch  reads  a  value  &om  a  specified  memory  location  and  places  it  into  a  local  register. 
Fetch  is  called  with  four  arguments:  the  user  doing  the  fetching,  the  register  into  which  the  new 
value  will  be  written,  and  the  virtual  address  of  the  memory  block  and  physical  offset  within  the 
memory  block  of  the  new  value.  The  with  clause  in  the  definition  describes  the  system  state  that 
will  result  from  applying  Fetch.  The  original  system  state,  which  is  described  in  the  full  Millen 
system  definition  given  in  subsection  6.8,  is  Memory,  Register,  Mmu,  CurrentUid,  WaitingUid  ; 
thus,  Fetch  is  defined  to  modify  only  the  Register  portion  of  the  system  state. 

The  produces  clause  describes  the  actual  difference  of  the  operation:  the  value  of  register  Rn 
for  User  will  be  changed  from  its  previous  value  (DontCare)  to  the  new  value  (New).  The  value 
DontCare  indicates  that  the  actual  value  that  was  originally  stored  in  register  Rn  does  not  affect 
the  validity  of  the  Fetch  operation.  The  by  clause  states  that  this  modification  is  produced  by  the 
architecture  rule  doStoreReg\  this  rule  is  the  one  that  the  PLANNER  uses  to  modify  its  internal 
version  of  state.  Architecture  rules  are  described  in  more  detail  in  a  later  section. 

The  with  clause  introduces  the  preconditions  that  must  hold  before  Fetch  may  actually  be 
applied.  In  this  example,  the  three  preconditions  state  that  (1)  there  is  a  physical  memory  location 
which  contains  the  value  New,  (2)  User  has  access  to  that  location  (i.e..  User  has  a  virtual  address 
corresponding  the  the  physical  block  address),  and  (3)  User  is  currently  active  (i.e.,  the  user  id  of 
the  currently  active  user — CurrentUid — ^is  identical  to  User).  If  any  of  these  preconditions  does  not 
hold  at  a  stage  in  the  plan  where  the  PLANNER  wishes  to  apply  Fetch,  then  the  PLANNER  will 
make  them  subgoals  and  attempt  to  achieve  them  first.  If  these  subgoals  cannot  be  achieved,  then 
the  PLANNER  cannot  add  Fetch  to  the  plan. 

Associated  with  each  of  the  preconditions  there  is  a  trigger  and  a  difference  clause.  These 
clauses  are  used  to  indicate  ways  in  which  the  preconditions  can  be  satisfied  if  they  are  not  currently 
true.  The  trigger  clause  specifies  the  particular  component  of  state  that  must  be  modified.  For 
example,  if  there  is  a  memory  location  containing  the  desired  information  but  the  current  user 
cannot  access  it  (i.e.,  memMap  fails),  then  the  PLANNER  triggers  a  change  in  current  user  Uid.  The 
difference  clauses  describes  the  exact  difference  that  must  be  achieved  in  order  for  the  precondition 
to  be  satisfied. 

Operation  rules  are  used  by  the  system  to  create  steps  in  the  plan.  As  mentioned  earlier,  the 
PLANNER  operates  by  trying  to  achieve  goals  which  are  stated  as  differences  between  states.  The 
PLANNER  starts  from  a  given  final  state  and  works  backward  to  satisfy  the  pven  initial  state. 
(Recall  that  information  flow  to  a  user  A  is  defined  here  as  information  that  was  not  available  to 
A  in  the  initial  state  but  is  available  to  A  in  the  final  state.  For  the  Millen  system,  information  is 
considered  to  be  available  to  a  user  when  it  is  in  one  of  that  user’s  registers.)  When  the  PLANNER 
is  working  on  a  particular  goal,  it  searches  through  the  system  operations  until  it  finds  one  which 
has  a  postcondition  containing  the  desired  difference.  In  our  example,  the  PLANNER  would  select 
Fetch  to  achieve  the  goal  of  modifying  a  register’s  contents.  In  order  to  use  an  operation,  the 
PLANNER  must  ensure  that  the  operation  preconditions  hold  at  the  point  in  the  plan  where  it 
is  to  be  used.  These  preconditions  are  then  subgoals.  Note  that  preconditions  do  not  themselves 
contain  operations,  but  only  architecture  rules  (described  later). 
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operation  Feteh(User,  Rn,  Mvirtxial,  Mn)  with 

state  Memory,  RegisterOut,  Mmu,  Current  Uid,  Waiting  Uid 

produces  Register: 

[[  User,  Rn,  DontCareJ  .  C  User,  Rn, 

by  (loStor«Rag(  Register.  User.  Rn.  Neural.  RegisterOut) 

with 

precond  fetchMemory(Memory,  Mpkys,  Mn,  New) 
trigger  Memory 

difference  CCMphys,  Mn,  undefined].  [Mphys.  Mn,  Meuval]] 
end  ; 

precond  memMap(Mmu,  User,  Mvirtual,  Mphys) 
trigger  Uid 

difference  CCOid]  >  CHaitingUid]] 
end  ; 

precond  equal(CurrentUid,  User) 
trigger  Uid 

difference  CCUid] .  [HaitingUid]] 
end 

Figure  2:  High-level  description  of  Fetch:  R{i) «—  Mem{j,  k) 

Some  complications  can  arise  when  an  operation  has  more  than  one  postcondition,  since  all 
of  the  postconditions  of  an  operation  miut  hold  at  the  stage  in  the  plan  fc^owing  the  operation’s 
application.  If  one  of  the  operation’s  postconditions  does  not  hold,  it  is  necessary  to  insert  a  subplan 
between  these  stages.  The  initial  state  of  the  snbplan  corresponds  to  the  state  that  holds  after  the 
current  operation  is  applied  (i.e.,  operation  postconditions  hold),  and  the  goal  state  is  the  one  to 
which  the  operation  is  to  be  prepended  (see  Figure  3). 

Architecture  rules:  The  PLANNER’S  architecture  rules  are  used  internally  by  the  PLANNER 
to  modify  its  view  of  the  system  state.  They  may  also  be  considered  predicates  on  the  state  that 
are  instantiated  or  revoked  depending  upon  the  operation  being  applied.  For  example,  in  a  system 
containing  a  collection  of  registers,  there  must  be  architectural  rules  that  will  allow  the  PLANNER 
to  observe  and  modify  renter  values  within  the  current  state.  Alternately,  one  may  consider  the 
system  to  contain  predicates  such  as  "Register  I  of  user  A  has  value  X”  and  "Register  I  of  user  A  is 
modified  to  contain  value  X.”  Architectural  rules  are  used  within  the  plan  to  describe  preconditions 
and  postconditions. 

High-level  System  Description:  As  was  alluded  to  in  an  earlier  section,  the  PLANNER  is 
written  in  Prolog.  However,  a  high-level  translator  has  been  developed  so  that  it  is  not  necessary 
for  the  user  to  describe  entire  systems  directly  using  Prolog  code.  This  translator  is  capable  of 
generating  most  of  the  planning  rules  and  operation  rules,  and  some  of  the  difference  computation 
rules.  It  is  still  necessary  for  the  user  to  write  Prolog  code  describing  most  of  the  difference 
computation  rules  and  the  architecture  rules.  Fortunately,  there  are  not  many  of  these  and  they 
tend  to  be  easy  to  formulate.  The  full  high-level  description  of  the  Millen  system  is  given  in  the 
Extended  Examples  Section  6.8. 
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Figure  3:  Insertiou  of  a  subplan 

7.5.3  Planner  input  vs.  specification  input 

There  are  many  similarities  between  the  high-level  description  of  the  planner  and  the  generic 
specification  of  the  system.  Both  systems  contain  an  internal  state  and  operation  descriptions. 
The  preconditions  of  the  PLANNER’S  operation  rules  correspond  to  the  security  policy  described 
in  the  generic  spediication.  The  postconditions  of  the  PLANNER’S  operation  rules  correspond 
to  the  functional  description  of  the  operations  in  the  generic  specification.  Further,  plans  found 
by  the  PLANNER  are  executable  by  the  generic  specification  (see  Figrue  4).  At  present,  the 
PLANNER  does  not  contain  all  of  the  information  in  the  full  specification:  for  example,  there 
is  no  explidt  history,  interpreter  or  scheduling  policy.  The  PLANNER  does,  however,  contain 
history  information  implidtly  in  the  plan  that  it  produces.  An  interpreter  is  not  necessary  for  the 
PLANNER,  since  it  uses  the  expanded  version  of  user  operations  to  generate  plans.  However,  it  is 
easy  to  find  examples  where  the  scheduling  policy  of  a  system  can  itself  be  either  a  source  of  flow 
violations,  or  may  eliminate  certain  types  of  flow.  The  only  notion  of  scheduling  available  to  the 
PLANNER  lies  in  its  ordering  of  goals,  and  the  preconditions  assodated  with  operations. 

7.5.4  Examples 

An  obvious  example  of  insecure  flow:  This  section  describes  the  path  which  the  PLANNER 
foUows  to  come  up  with  a  very  simple  example  of  information  flow.  The  operations  available  to  the 
PLANNER  indude  all  of  those  used  by  the  general  Millen  operating  system,  plus  two  that  have 
been  added  to  induce  flow:  ReadX,  WriteX.  The  Millen  operating  system  has  been  expanded  to 
indude  a  spedal  system  register  X,  which  any  user  may  read  or  modify  using  the  new  operations. 
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Figure  4:  Planner  and  SRM  specification 

Gearly,  flow  between  users  may  occur  via  this  special  register.  To  further  simplify  the  example,  the 
system  is  assumed  to  contain  only  two  users,  each  with  exclusive  access  to  two  blocks  of  memory. 
At  each  step  in  the  plan,  the  system  state  and  the  plan  state  will  be  given. 

The  PLANNER  is  given  the  goal  of  Ending  a  plan  whereby  one  user  obtains  information 
originally  contained  in  the  second  user’s  memory.  This  is  stated  by  defining  an  initial  state  where 
User  I’s  block  does  not  contain  User  2’s  information,  and  a  final  state  where  User  I’s  block  does 
contain  User  2’s  information.  Recall  that  we  are  working  backwards  from  the  final  state  toward 
the  initial  state. 

Initial  state: 

^  R{Userl,i):s  Ri  R(l7ser2,»)  *  ■Rr  Mem{0,k)  —  Mo  '' 

Mmv.{U aer\,m)  =  0  Mmu{Uaei12tj)  =  1  jlfem(l,Jb)  =  Secret 
X  =  DontCare 

^  Current  user  —  2  ^ 

Final  state: 

^  R[UaeTl^i)  =  Secret  R(Uaer2,i')  =  R2  Mem(0,k)  =  Af©  \ 

Mmu{V  aeTl,m)  =  0  Mmu{Uaer2,j)=  1  Mem{l,k)  =  Secret 
X  =  DontCare 

^  Current  user  =  1  j 

1.  Mem(Mmu(Uaerl,m),k)o^  Mem(Mmii(Uaer2,j),k)o  ^  0 
Mem(Mmu(Daerl,m),k)t  =  Mem{Mmu{Uaer2,j),k)i  ^  0 

To  shorten  the  plan,  use  User2  as  the  active  process  initially  and  Userl  as  the  active  process 
in  the  final  state.  (The  PLANNER  will  produce  a  correct  plan  even  if  this  is  not  the  case.) 


172 


Possible  Plaoas  for  Goal  1: 

•  Store{i,'m,k)  by  tJserl,  with  R{Userl,i)  =  Mem{Mmv,{User2,j),k)Q 

•  Purge{Mm‘u{Userl,m)) 

There  are  two  possible  plans,  since  two  operations  contain  a  postcondition  with  a  modified 
memory.  However,  Purge  can  only  write  0  into  memory  and  we  have  excluded  0  as  a  possible 
secret  message. 

Choose  plan  Store(x,m,k). 

...  Siore{i^m,k) 

This  sets  up  a  new  goal: 

2.  R{UseTl,i)  =  Mem{Mmu{User2,j),k)o  Possible  Plans  for  Goal  2: 

•  Feteh^i^j^k)  with  t=0 

•  ReadX{i)  with  X  =  Mem{Mmu{UseT2,j),k)o 

(Either  possibility  will  produce  a  valid  plan  here.  If  plan  Fetch  is  chosen,  the  PLANNER  will 
attempt  to  satisfy  the  precondition  that  there  must  be  a  register  within  Userl’s  register  set 
containing  the  value  in  User2’s  block.  This  produces  a  longer  plan,  so  for  illustration,  ReadX 
will  be  chosen.) 

Choose  plan  ReadX(i). 

U-rl 

...  ReadX {i)  Store{i,m,k) 

This  sets  up  a  new  goal: 

3.  X  =  Mem{Mmu{UaeT2,j),k)o  Only  a  WriteX  can  cause  X  to  contain  the  desired  value. 
The  problem  is  that  the  current  process  cannot  do  the  write,  since  it  does  not  have  User2’E 
information.  Thus,  User2  must  have  done  the  write  into  X  earlier.  This  sets  up  a  subgoal 
that  must  be  achieved  before  goal  3  can  be  achieved. 

4.  Current  process  =  U»er2 
Possible  Plans  for  Goal  4: 

•  Suiap 

Only  one  possible  plan,  so  choose  plan  Sump  and  propagate  the  goal  3. 

Vaar3  _ U»frl _ 

...  Swap  ReadX (i)  Stare(i,m,k) 

The^’e  is  now  a  plan  for  goal  3  which  may  be  applied:  Possible  Plans  for  Goal  3: 
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•  WriteX 

Choose  plan  WriteX(i).  The  plan  now  becomes: 

Vt€r2  UtrX 

...  H^rttejr(t)  Svtap  ReadX(i)  Store{i,m,k) 

This  sets  up  a  final  goal: 

5.  Rf{Vser2^i)sz  Mem{Mmu{j)fk)o 

This  may  be  achieved  directly  by  plan  Feteh(i,  j,  k). 

Thus,  the  resultant  plan  it: 

_ yy3 _ _ 

Fetek{i,j,k)  WriteX (i)  Swap  ReadX{i)  Store{i,m,k) 

A  more  subtle  example  of  insecure  flow:  The  previous  example  described  an  obvious  example 
of  flow  that  was  easily  discovered  by  the  PLANNEE.  In  that  example,  mformation  was  directly 
transferred  from  one  user  to  another.  This  section  describes  a  more  complex  example  of  information 
flow  where  information  is  transferred  indirectly.  Here,  one  user  will  observe  one  of  two  possible 
results,  depending  upon  the  actions  of  a  second  user.  The  operations  used  in  creating  this  plan  are 
those  described  in  subsection  6.6,  excluding  both  the  Compute  operations  and  the  two  operations 
that  modify  register  X, 

Some  new  notation  will  be  introduced  at  this  point.  Objects  and  operation  names  may  be  sub¬ 
scripted  with  plan  stages:  Rt(U,i),Storet{i,j^k),  Plan  goals  such  as  may  also  be  subscripted 
with  a  user  level  to  in^cate  that  they  may  only  be  satisfied  by  a  user  operating  at  that  particular 
level.  For  example,  Rt(U,i)  jiy  SciU,i)  indicates  that  user  fTs  register  i  at  plan  stage  t  must  not 
have  the  same  value  that  it  did  at  plan  stage  0-,  further,  the  change  in  value  must  have  been  caused 
by  a  user  operating  at  level  y. 

The  following  describes  the  reasoning  the  PLANNEE  could  use  to  locate  such  a  security  flaw. 
The  relevant  part  of  the  system  state  is  shown  in  this  format: 

/  Mmu(X,j)  =  bi  ifmu(y,i)  =  63  Mem{bi,k)  =  Id  \ 

\R{X,i)^Rx  R{Y,i)^R2  ) 

1.  Rt{X,i)^yRa{X,i) 

The  initial  goal  of  the  system  is  to  find  a  plan  where  user  X  has  a  different  value  in  one 
of  its  registers  if  user  Y  takes  a  particular  action  (note  that  this  violates  the  restrictiveness 
property).  Only  user  X  can  modify  JZt(X,  t).  Possible  Plans  for  Goal  1: 

•  Fetd^i,j,k)  Iqr  user  X 

Thus,  goal  1  win  be  achieved  when  the  foQowing  goal  is  achieved: 

2.  ifewH_i(Jifmtt(X,j),t)#e 

To  folfin  this  goal,  we  must  ensure  that  something  other  than  Ro{X,  t)  is  written  into  the 
memory  block  bi,  where  bi  s  i/fn«t-i(X,  j).  Since  this  inequality  is  restricted  to  be  caused 
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by  user  Y,  user  Y  must  have  had  access  to  the  block  at  some  stage  in  the  plan.  The  current 
plan  looks  like  this: 


UttrX  UtrY  UttrX 


. . .  Swap . . .  Swap . . .  Fetch(i,j,k) 


User  Y  cannot  modify  memory  unless  it  has  a  pointer  to  it  in  its  Mmu.  Both  users  cannot 
point  to  memory  simultaneously,  so  user  X  must  have  regained  access  to  the  memory  block 
after  Y.  This  sets  up  a  new  goal: 

3.  Mmut-3{X,j)  =  6i 
Possible  Plans  for  Goal  3: 

•  Get(buj) 

The  preconditions  to  this  operation  require  block  bi  to  be  active,  have  no  other  user  accessing 
it,  and  have  the  proper  security  level,  leading  to  three  new  goals: 

4.  hi  is  active 

5.  bi  is  unused 

6.  bi  has  level  X 

Possible  Plans  for  Goal  6: 

•  Raise{bi) 

This  plan  also  achieves  goal  4.  The  goals  which  still  need  to  be  achieved  are:  2,  5.  Possible 
Plans  for  Goal  2: 

•  Piirge(bi) 

This  portion  of  the  plan  should  take  place  before  user  Y  performs  Swap,  since  user  X  no 
longer  has  access  to  bi  here.  The  current  plan  and  system  state  at  t  —  4  are: 

V„rX  UtwrY  Ut€rX 

>/  '  ■  . . . 

. . .  Swap . . .  Purget.4{bi)  Swap...Raise{j)  Get(bj,j)  Fetch(i,j,k) 

(  Mmw{X,i)  =  6n  =  bx  Mem{bi,k)  =  o\ 

\RiX,i)=Rx  R{Y,i)  =  R2  ) 

Note  that  goa!  2  has  been  achieved,  since  bi  now  contains  0  after  the  Purge.  It  is  necessary  to 
achieve  the  preconditions  of  Purge  (same  as  goal  5).  This  goal  is  achieved  as  a  side  effect  of 
Get,  since  that  is  the  only  operation  which  makes  blocks  available  to  the  system.  Additionally, 
since  we  assumed  that  user  X  originally  had  bi,  it  makes  sense  to  place  this  plan  before  user 
X’s  first  Swap.  Assuming  that  User  X  initialised  R{i)  to  something  other  than  0,  the  plan 
and  initial  system  state  become: 

_ Vt^X _ _ Vt^X _ 

Initialise  Get(63,j)  Swap  Purget-4{bi)  Swap  Raise{j)  Get{bi,j)  Fetch{i,j,k) 
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/  j)  =  6a  Afmii(y,i)  =  6n  Afem(6i,  *)  =  X  /  0  \ 

^^(A-.t)=JJa  JZ(y,0=i22  ) 

A  necessary  component  of  this  plan  is  that  the  system  is  in  collusion  with  the  users,  since  a 
user  cannot  directly  name  blocks  or  force  the  system  to  obtain  a  particular  block. 

7.6  Conclusions  and  future  directions 

Although  verification  of  secure  operating  systems  specifications  is  important  and,  hopefully,  feasi¬ 
ble,  testing  is  also  important  and  less  expensive  than  verification  at  discovering  flaws.  Furthermore, 
testing  can  be  used  to  discover  properties  of  a  system  aside  from  those  related  to  security.  Accord¬ 
ingly,  we  have  developed  two  testing  tools  as  a  first  step  towards  an  automated  testing  methodology 
fat  secure  sjrstems. 

The  first  tool  is  based  on  the  EASE  executable  specification  language.  EASE  has  the  advantages 
of  an  algebraic  language  (abstraction,  parameteiixation,  and  error  handling)  but  has  the  intuitive 
feel  of  an  operational  luiguage.  The  EASE  tool  is  used  to  execute  specifications  with  real  values.  To 
facilitate  the  testing  of  specifications  for  a  secure  operating  system,  we  have  written  a  specification 
for  a  generic  secure  resource  manager  (SRM)  in  EASE,  the  specifications  being  a  template  for  a 
large  class  of  secure  operating  systems.  Although  it  remains  to  be  determined  that  the  SRM  is  a 
suitable  template  for  many  of  the  operating  systems  of  interest,  our  initial  experience  has  convinced 
us  that  generic  specifications  are  possible  for  an  operating  system  and  for  its  security  policies;  at 
the  abstract  level,  operating  systems  have  much  in  common.  Although  the  generic  feature  is  lost 
at  lower  levels  of  abstraction,  EASE  can  be  used  to  mix  spedficatioiu  with  decisions  expressed 
imperatively. 

The  second  tool,  the  PLANNER,  is  used  to  derive  a  sequence  of  operations  that  exhibits  a 
security  flaw,  usually  a  covert  channel.  It  is  based  on  classical  planning  techniques,  but  extended 
to  handle  goals  that  express  a  flow  of  information  between  processes.  Different  from  the  classical 
planners,  PLANNER  is  specialised  to  the  domain  of  security  flow.  This  specialization  has  led  to  a 
system  whose  performance  is  better  than  that  achievable  with  a  general  planner. 

Both  the  SRM  and  the  PLANNER  have  been  evaluated  on  small  examples.  The  main  example 
is  an  operating  system  described  by  Millen,  whose  purpose  is  to  demonstrate  security  verification. 
Its  main  operating  system  features  are  process  switching  including  swapping,  and  reclaiming  of 
memory  blocks.  Although  clearly  a  toy,  it  has  the  basic  features  of  a  multiprogrammed  operating 
system  with  dynamic  allocation  of  main  memory. 

Clearly,  it  is  essential  to  conuder  larger  systems.  A  suitable  next  step  would  be  a  system  based 
on  MINIX,  an  operating  system  with  the  system  calls  of  UNIX,  but  a  vastly  simpler  kernel. 

We  have  several  improvements  in  mind  for  EASE.  Currently,  many  uses  of  quantifiers  lead  to 
specifications  that  are  not  executable.  When  EASE  is  unable  to  execute  a  quantified  expression, 
the  user  has  no  choice  but  to  try  a  different  specification.  We  are  consideiing  a  feature  whereby 
a  user  can  define  an  implementation  for  a  quantified  expression  (such  as  through  an  iterator  over 
a  type).  Furthermore,  EASE  can  execute  only  spedficatioiu  with  respect  to  real  values  of  input. 
Extensions  to  symbolic  evaluation  would  improve  its  utility  in  testing,  but  at  the  cost  of  producing 
complicated  expressions  to  the  user. 

The  SRM  is  an  initial  step  towards  a  generic  operating  system  specification.  It  should  be 
extended  to  indude  additional  features  in  support  of  distributed  systems.  A  good  first  step  would 
be  generic  message  passing  and  remote  procedure  call. 
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The  PLANNER’S  primitive  search  strategies  work  for  operating  systems  that  contain  relatively 
few  operations.  As  the  number  of  operations  increases,  so  does  the  the  probability  of  the  PLANNER 
making  poor  choices  in  attempting  to  achieve  goals.  Heuristics  are  needed  to  help  the  planner  in 
making  choices. 


177 


7.7  Extended  Examples 

This  labsection  contain*  detail*  of  the  MITRE  *y*tem  *peciiication  need  in  the  planner  and  *peci- 
fication  detail*  for  the  Millen  example. 

7.7.1  Description  of  Millen  system  operations 

Thi*  section  describe*  the  modified  Millen  operating  system  operations  nsed  in  the  generic  specifica¬ 
tion  and  in  the  planner.  Table  3  contains  the  commands  that  only  the  operating  system  supervisor 
may  issue  (i.e.,  requires  privileged  mode).  All  block  addresses  used  in  these  commands  are  the 
physical  block  addresses.  Table  4  contains  the  commands  that  only  the  users  may  issue  (requires 
unprivileged  mode).  All  block  addresses  used  in  these  commands  are  virtual  addresses,  which 
transformed  to  physical  addresses  via  the  memory  management  unit  (MMXT). 

The  Millen  system  has  been  modified  so  that  each  user  has  its  own  MMTJ  and  register  set  R, 
thus  aUTniwa-titig  the  need  for  the  private  storage  areas  described  in  the  oxif^al  paper. 

In  the  operations  described  below,  the  following  notation  is  used: 

b  Physical  block  number 

j  Virtual  block  number 

k  Offset  within  block 

R '  New  value  of  R  (after  operation) 

t,m  Re^ster  index 

There  are  several  system  variables  appearing  in  the  operation  tables  that  have  not  yet  been 
discussed.  These  variables  are  used  in  the  ori^al  Millen  specification  to  enforce  security  con¬ 
straints.  The  meaning  of  each  of  these  is  ^ven  below: 

Cp  Current  process  id 
Pol(c)  Security  (access)  level  of  user  process  c 
Bal(h)  Security  level  of  block  h 
Bap(h)  Activity  status  (block  in  use)  of  block  b 
Bce(b)  Number  of  processes  with  acceM  to  block  b 
Bdf(b)  Indicates  whether  block  b  is  attached  to  an  10  device 
The  security  system  used  in  the  Millen  operating  system  relies  upon  distinct  security  levels. 
These  levels  are  not  ordered  in  the  low  water  mark  sense:  a  user  may  only  gain  access  to  a  block  at 
its  own  level.  Blocks  can  change  level  via  the  system  command  Pttrpe,  which  sets  the  block  security 
level  equal  to  syshi  (a  level  which  no  user  process  can  reach).  Block  levels  are  also  modified  by 
system  command  G€t(b,n):  this  command  is  issued  on  behalf  of  a  user  process,  and  causes  the 
block  level  to  match  the  user  security  level,  bi  addition,  the  user’s  MMTJ  is  set  to  pmnt  to  the 
block,  which  has  the  side  effect  of  ndeasing  one  of  the  user’s  current  blocks. 
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Plan 

Preconditions 

Postconditions 

Purge{b) 

Bac{b)  =  0 
^Bdf(b) 

mode  =  privileged 

Bal'{b)  =  syshi 
^Bop'(i) 

^kMem'{b,k)  =  0 
mode  =  unpriv 

Raise{b) 

-'Bap{b) 

mode  =  privileged 

Bal'ib)  =  PaliCp) 
Ba]/{b) 

mode  =  unpriv 

Get(b,  n) 

Bap{b) 

Bae(b)  =  0 

Balib)  =  PaliCp) 
mode  =  privileged 

Baef{b)=l 
Bae'lMMUin))  =  0 
MMV\n)  =  b 
mode  =  unpriv 

Swap 

mode  =  privileged 

Cp'  =  (Cp  +  l)mod  P 

Table  3:  Commands  issued  by  the  supervisor 


Plan 

Preconditions 

Postconditions 

Fetek{i,j,k) 

mode  s  unpriv 

R'{i)s:  Mem{MMU{j),k) 

mode  =  unpriv 

Mem'{MMU{j),k)s  R{i) 

Computek{m) 

mode  =  unpriv 

R>(m)  =  fk{OR{m)) 

Table  4:  Commands  issued  by  users 


Plan 

Preconditions 

Postconditions 

RtadX{i) 

mode  =  privileged 

£'(»)  =  ^ 
mode  =  unpriv 

WTiteX{i) 

mode  =  privileged 

X'  =  R'[i) 
mode  =  unpriv 

Table  5:  Commands  added  to  induce  a  flow  violation 
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7.7.2  Specification  of  the  Millen  example 

SRN  /*  kind  1  */ 

/*  Secure  Resource  Meneger  «/ 

stateolSRM  :  SRM  ->  State 
opsofSRN  :  SRM  ->  SRMopSet 
scbedofSRM  :  SRM  ->  Scheduler 
interpofSRM  :  SRM  ->  Interp 
polofSRM  :  SRM  ->  SecPol 

initSRM  :  QbjeetSet  ProcessSet  Re^estList  SRMopSet  Scheduler  Interp  SecPol 
->  SRM 

neereqSRM  :  Request  SRM  •>  SRM 
stepSRM  :  SRM  ->  SRM 

OISTIIGUISHING  SET  stateofSRM  opsofSRM  schedofSRM  interpofSRM  polofSRM; 

initSRM  (OB.  PR.  RL.  OP.  SCH.  ZRT.  POL)  » 

CinitScate(OB.PR.RL).  OP.  SCH.  IMT.  POL] ; 

nevreqSRM  (r.  H)  ■> 

CaddreqState(r,stateofSRM(M)) . 

opsofSRMCM).  schedofSRM (M) .  interpofSRM (M) .  polofSRM (N) ] ; 
stepSRM  (M)  -> 

CstepState(stateofSRM(M) . schedofSRM (M) , interpofSRM (M) , polofSRM (M) ) . 
opsofSRMCM).  schedofSRMCM).  interpof SRM(M) .  polofSRM(M)] ; 
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Stata  /•  kind  1  •/ 


/*  Tha  oparation  updataobjStata  is  a  darive  oparation  includad  for 
convanianca  in  this  application.  */ 

/*  This  spacif ication  contains  tha  dafinition  of  tha  most  cantral  oparation 
of  tha  antira  spacif ication,  stapStata.  */ 

trivStata  :  ->  Stata 

initStata  :  ObjactSat  ProcassSat  RaquastList  ->  Stata 

updhistStata  :  Raquast  Stata  ->  Stata 

addobjStata  :  Objact  Stata  ->  Stata 

addprocStata  :  Procass  Stata  ->  Stata 

addraqStata  :  Raquast  Stata  ->  Stata 

ramobjStata  :  Objact  Stata  ->  Stata 

ranprocStata  :  Procass  Stata  ->  Stata 

ramraqStata  :  Int  Stata  ->  Stata 

objsof Stata  :  Stata  ->  ObjactSat 

procsofStata  :  Stata  ->  ProcassSat 

raqsofStata  ;  Stata  •>  RaquastList 

histofStata  :  Stata  •>  History 

stapStata  :  Stata  Schadular  Zntarp  SacPol  >>  Stata 

updataobjStata:  Objact  Objact  Stata  >>  Stata 

DISTINGUISHING  SET  objsof Stata  procsofStata  raqsofStata  histofStata; 
trivStata  «> 

CamptyObjactSat,  amptyProcassSat ,  nilRaquastList ,  initHistory (trivStata)] ; 
initStata  (0,  P,  R)  ■>  [0,  P,  R,  initHistory(initStata(0,P,R))] ; 
updhistStata  (r,  S)  ■> 

[obj sof Stata (S) ,  procsofStata (S ) ,  raqsofStata (S) , 
appandHistory(r .histofStata (S))] ; 

addobjStata  (o,  S)  ■> 

[addOb j  actSat (o , obj  sof Stata (S) ) . 
procsofStata(S) ,  raqsofStata (S) ,  histofStata(S)] ; 

addprocStata  (p,  S)  ■> 

[obj sof Stata (S) .  addProcassSat (p .procsofStata (S) ) , 
raqsofStata (S) .  histofStata(S)] ; 

addraqStata  (r.  S)  ■> 

CobjsofStata(S) ,  procsofStata (S) ,  appandRaquastList (r.raqsof Stats (S) ) . 
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hiatofStat«(S)] ; 


raaobjStata  (o.  S)  ■> 

[ramOb jactSat (o .objsof Stata(S) ) , 
procsofStata(S) ,  raqaofStataCS) ,  hiatofStata(S)] ; 

ranprocStata  (p,  S)  ■> 

CobjsofStataCS) .  ramProcasaSat(p.procaofStata(S)) , 
raqsofStata(S) .  hiatofStata(S)] ; 

raaraqStata  (n.  S)  ■> 

CobjsofStataCS).  proesofStata(S) ,  raaRaquastListCn.raqsofStataCS))  , 
histofStata(S)] ; 

stapStata  (S.  SCB,  I.  P)  ■> 

lat  R  ba  gatraqSchadular(SCH.S)  in 
lat  SS  ba 

updhistStataCR. 

CobjsofStata(S),  procsofStataCS) ,  gatraqlisSchadularCSCH.S) , 
RistofStataCS)])  in 
lat  RR  ba  gatraqSacPoKSS.R.P)  in^ 
lat  RRI  ba  gatraqlntarp(SS,RR,I)  in 

lat  f  ba  opofRaquaat(RRI)  and  A  ba  argsofRaquastCRRI)  in  apSRMopCf .SS.A) ; 
npdataobjStata  (ol,  o2.  S)  ■>  addobjStata(o2.raBobjStata(ol,S)) ; 
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ProcassSst  /*  kind  1  */ 


/*  This  is  an  implamantation  of  tha  “ideal"  ProcassSat  specification  that  is  better 
for  interactive  use  in  that  it  speeds  the  computation  necessary  to  display  a 
ProcessSet  and  to  perform  the  operation  f indinProcessSat .  These  things  could,  in 
principle,  be  done  by  allowing  quantifiers  (specifically,  tha  “some"  quantifier) 
in  the  definitions  of  f indinProcessSat.  f irstinProcassSet ,  and  rastof ProcessSet ; 
such  definitions  would  remain  executable  in  the  FiSE  system.  */ 

emptyProcassSet  :  *>  ProcessSet 
addProcessSat  :  Process  ProcessSet  ->  ProcessSet 
ramProcessSet  :  Process  ProcessSet  •>  ProcessSet 
isinProcessSet  :  Process  ProcessSet  ->  Bool 
f indinProcessSat  :  ProcassPred  ProcessSet  ->  Process 
firstinProcessSat  :  ProcessSet  ->  Process 
rsstofProcsssSat  :  ProcessSet  ->  ProcessSet 
isemptyProcassSat  :  ProcessSet  ->  Bool 

DISTINGUISHING  SET  firstinProcessSat  rastofProcassSat ; 

emptyProcassSet  «>  C  errProcess .  emptyProcassSet  ] ; 

isinProcessSet  (p,  S)  •> 
if  isaaptyProcessSet  (S) 
thee  false 

else  (p  ■  f irstinProcassSet (S)  I  isinProcessSet (p.restof ProcessSet (S))} ; 
addProcessSat  (p,  S)  ■> 

if  isemptyProcessSetCS)  I  precedesProcessCp,  firstinProcessSat (S)) 
than  Cp,  S] 

else  if  p  ■  f irstinProcassSet (S) 
then  S 

else  [  f irstinProcassSet (S) , 

addProcassSet (p.restof ProcessSet (S))  ]  ; 

ramProcessSet  (p,  S)  ■> 

if  isaaptyProcessSet (S)  then  S 

else  if  p  ■  f irstinProcassSet (S)  then  restofProcassSet(S} 
else  C  f irstinProcassSet (S> , 

reaProcessSet (p.restof ProcessSet (S)}  ]  ; 

isaaptyProcessSet  (S)  ■>  iserrProcass (firstinProcessSat (S) ) ; 

f indinProcessSat  (P,  S)  ■> 
if  isaaptyProcessSet (S) 
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than  arrProcaas 

alsa  lat  o  ba  f irstinProcassSatCS)  in 
If  apProcaasPradCP.o) 
than  o 

alaa  f indinProcassSatCP.rastofProcasaSatCS) } : 
isamptyProcassSat  (S)  «>  IsarrProcaaaCfirstinProcassSatCS)) ; 
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ProcassPrad 


/*  Tha  sort  ProcassPrad  azists  in  ordar  to  make  the  definition  of 

findinProcassSat.  useful  in  tha  definitions  of  many  SRMops,  independent 
of  tha  application.  */ 

/*  Only  tha  constructor  isidProcassPrad  is  specific  to  this  application.  •/ 

apProcassPrad  :  ProcassPrad  Process  ->  Bool 
trivProcessPrad  :  Bool  ->  ProcassPrad 
isidProcassPrad  :  Procassid  *>  ProcassPrad 

DISTINGUISHING  SET  apProcassPrad; 

tritProcassPrad  (b)  •>  [<p>  l->  b] ; 

isidProcassPrad  (i)  ■>  C<p>  l*>  idof Process (p)  ■  i] ; 
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ProcMs  /«  kind  3  •/ 


/*  Only  th«  n«B«  and  arity  of  tha  oparator  idofProcaas  is  part  of  tha  tamplata 
spacif ication.  «/ 

idofProcass  :  Procass  ->  Procaasid 
aqProcass  :  Procass  Procass  ->  Bool 
inofProcass  :  Procass  ->  Bool 
ISTOfProcass  :  Procass  ->  Laval 
MBblkof Procass  :  Int  Procass  ->  Ob j  act 
ragof Procass  :  Int  Procass  ->  Ob j act 
systaaProcaas  :  •>  Procass 
■kusarProcass  :  Int  Laval  Int  ->  Procass 
svapinProcass  :  Procass  ->  Procass 
svapontProcass  :  Procass  *>  Procass 
pracadasProcass  :  Procass  Procass  ->  Bool 
isprivllagad  :  Procass  ->  Bool 
isragofProcass  :  Int  Procass  ->  Bool 
updragProcass  :  Procass  Int  Contant  ->  Procass 
updaamblkProcass  :  Procass  Int  Ob j act  >>  Procass 

OISTIIGUISHIVG  SET  idofProcass  inofProcass  lavofProcass 
ragof Procass  nanblkof Process; 

aqProcass  (pi,  p2)  •>  idofProcass (pi)  •  idofProcass (p2) ; 

systaaProcass  ■> 

[  sysProcassId,  trua,  syshi,  <n>  i->  arrObjact,  <n>  |->  arrObjact  ]; 

■kusarProcass  (i,  1,  k)  ■> 

[  ■kussrProcsssId(i) ,  falsa.  1, 

<n>  |*>  if  k  >  n  than  arrObjact 

alsa  akragObjactCakragObjactldCi.BkusarProcassIdCi)) . 
arrContant, 
arrLaval) . 

<n>  l->  arrObjact  ] ; 

svapinProcass  (p)  ■> 

[idofProcass (p) ,  trua,  lavofProcass (p), 

<n>  |->  ragofProcass(n,p),  <n>  I •>  saablkof Procass (n.p)] ; 

saapoutProcass  (p)  ■> 

[idofProcass (p) ,  falsa,  lavofProcass (p) , 

<n>  l->  ragof Procass (n, p) .  <n>  |->  aaablkof Procass (n, p)] ; 
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pr«c«dasProcass  (pi,  p2)  ■>  pracadasProcassldCidofProcassCpl) ,  idofProcass(p2)) ; 

isprivilagad  (p)  ■>  idofProcassCp)  •  aysProcassId; 

isragofProcass  (n.  p)  «>  ‘isarrObj act (ragof Process  (n.  p)); 

updragProcass  (p,  n,  c)  ■> 

CidofProcassCp) ,  inofProcassCp) ,  laTofProcassCp) , 

<B>  |->  if  man  than  updatacont0bjact(ragofProca8s(B,p) ,c) 
alaa  ragofProcaaa(B,p) . 

<B>  |->  BaBblkofProcaaa(B.p)] : 

updBeBblkProcaaa  (p,  n,  o)  ■> 

[idofProcaaa(p) .  inofProcaaa(p) .  lavofProcaaa(p) ,  <b>  |->  ragof Procaaa (b. p)  , 
<B>  |->  if  B^n  than  o  alaa  aaBblkofProcaaaCB.p)] ; 


R«qu*atList  /«  kind  1  */ 

nilRaquastList  :  •>  RaquastList 
nullRaquastList  :  R«qu«8tList  •>  Bool 
propondRoquostList  :  Roquost  RaquoatList  ->  RaquaatLiat 
appandRoquoatLiat  :  Raquaat  RaquaatLiat  >>  RaquaatLiat 
concatRaquaatLiat  :  RaquaatLiat  RaquaatLiat  •>  RaquaatLiat 
raaRaquaatLiat :  Int  RaquaatLiat  ->  RaquaatLiat 
hdRaquaatLiat :  RaquaatLiat  ->  Raquaat 
tlRaquaatLiat :  RaquaatLiat  ->  RaquaatLiat 

OISTIRCUISHIIG  SET  hdRaquaatLiat  tlRaquaatLiat; 

ailRaquaatLiat  ■>  CarrRaquaat .  nilRaquaatLiat] ; 

nullRaquaatLiat  (R)  ■>  iaarrRaquaat (hdRaquaatLiat (R) ) ; 

prapandRaquaatLiat  (r,  R)  ■>  [r,  Rj; 

appandRaquaatLiat  (r,  R)  ■> 

if  nullRaquaatLiat (R)  than  [r.  R] 

alaa  ChdR^uaatLiat(R) ,  appandRaquaatLiat (r. tlRaquaatLiat (R) )]  ; 

coneatRaquaatLiat  (Rl,  R2)  •> 
if  nullRaquaatLiat (Rl)  than  R2 

alaa  [hdRaquaatLiat (Rl ) ,  concatRaquaatLiat(tlRaquaatLiat(Rl) ,R2}] ; 

ranRaquaatLiat  (n,  R)  ■> 

if  nullRaquaatLiat (R)  than  R 
alaa  if  n  ■  1  than  tlRaquaatLiat (R) 

alaa  [hdRaquaatLiat (R) ,  ranRaquaatLiat (n>l, tlRaquaatLiat (R) )] ; 
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Request 


nullRequest  :  ->  Request 
opof Request  :  Request  ->  SRMop 
srgsofRequest  :  Request  ->  ArgList 
oktoRequest  :  Request  State  ~>  Bool 
procidofRequest  :  Request  ->  Processid 
mkRequest  :  SRMop  ArgList  Processid  •>  Request 

OISTINGUISHIHG  SET  opof Request  argsof Request  procidofRequest; 

nullRequest  ■>  [KOop,  errArgList.  sysProcessZd] ; 

mkRequest  (f.  A.  i)  »  [i,  A.  i] ; 

oktoRequest  (r.  S)  ■> 

isprivilegedCf indinProcessSet(isidProcessPred(procidofRequsst(r) ) . 

procsof State(S) ) ) ; 
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History  /«  kind  3  «/ 

/*  Only  tbs  opsrstions  initHlstory  and  appsndHistory ,  vith  thsir  dsclarad 
aritiss,  ars  part  oi  th«  tamplata.  Tbair  dsfinitions  and  tbs  rsoaining 
opsrations  ars  paculiar  to  tbis  application.  */ 

startHistory  :  History  ->  Stata 
listofHistory  :  History  ->  RaquastList 
initHistory  :  Stata  ->  History 
appandHistory  :  Raquast  History  ->  History 

DlSniGDISHIIG  SET  StartHistory  listofHistory: 

initHistory  (S)  ■>  [S .  nilRaquastList] ; 

appandHistory  (r.  H)  >>  [startHistoryCH) .appandRaquastListCr.listofHistoryCH))] ; 


ArgList  /*  kind  1  »/ 

nilArgList  :  ->  ArgList 
nullArgList  :  ArgList  ->  Bool 
sppsndArgList  :  Arg  ArgList  ->  ArgList 
hdArgList:  ArgList  •>  Arg 
tlArgList:  ArgList  ->  ArgList 
ntkArgList  :  Int  ArgList  ->  Arg 
IsngthArgList  :  ArgList  ->  Int 

DISTXICUISHXXG  SET  hdArgList  tlArgList; 

nilArgList  ■>  [srrArg.  nilArgList] ; 

nullArgList  (R)  ■>  issrrArg (hdArgList (R) ) ; 

sppsndArgList  (r.  R)  ■> 

if  nullArgList (R)  thsn  Cr.  R] 

slss  ChdArgList(R).  sppsndArgList (r. tlArgList(R) )] ; 

nthArgList  (n.  R)  ■> 
if  n<l  thsn  srrArg 
slss  if  nal  thsn  hdArgList (R) 
slss  nthArgList (n*l, tlArgList (R)); 

IsngthArgList  (R)  ■> 

if  nullArgList (R)  thsn  0  slss  1  ♦  IsngthArgList (tlArgList (R) ) ; 
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Arg  /•  kind  3  */ 


/«  Arg  is  an  application  dapandant  union  t3rpa  alloaing  a  variaty  of  arguments. 
Objactids  and  Procassids  ara  guaranteed  to  ba  vadid  arguments  in  any 
application,  and  banca  objidtoArg,  objidofArg,  procidtoArg,  and  procidofArg 
ara  part  of  the  tamplata.  Znt  and  ComputaFn  Args  are  special  to  this 
application.  The  get... Arg  operators  ara  also  special  to  this  application, 
but  se  anticipate  that  their  analogues  (which,  essentially,  select 
arguments  and  do  the  appropriate  coercions)  sill  be  useful  in  defining  the 
SRNops  of  most  other  applications  as  sell,  a/ 

objidtoArg  :  Object Id  ->  Arg 
procidtoArg  :  Processld  •>  Arg 
inttoArg  :  Int  ->  Arg 
fntoArg  :  ComputaFn  >>  Arg 
objidofArg:  Arg  ->  Objectid 
procidofArg:  Arg  ->  Processld 
intofArg  :  Arg  ->  Int 
fnofArg  :  Arg  ->  ComputaFn 
getblkidArg  :  Int  ArgList  *>  Objectid 
gatublkindArg  :  Int  ArgList  •>  Int 
getoffsetArg  :  Int  ArgList  ->  Int 
getregindArg  :  Int  ArgList  ->  Int 
getuidArg  :  Int  ArgList  >>  Processld 
getfnArg  :  Int  ArgList  •>  ComputaFn 

DISTIHGUISHIIIG  SET  objidofArg  procidofArg  intofArg  fnofArg; 
objidtoArg  (!)  ■>  [i,  errProcessId,  err  Int,  errC^uteFn] ; 
procidtoArg  (i)  ■>  [errObjectld,  i,  erxlnt,  errComputeFn] ; 
inttoArg  (n)  ■>  CerrObjactId,  errProcessId,  n,  errComputeFn]; 
fntoArg  (f)  ■>  [errObjectld,  errProcessId,  errint,  f ] ; 
getblkidArg  (n.  A)  ■>  objidofArg(nthArgList(n,  A)); 
gatublkindArg  (n.  A)  ■>  intofArg (nthArgListCn,  A}); 
getoffsetArg  (n.  A)  ■>  intofArg (nthArgListCn,  A)); 
getregindArg  (n.  A)  ■>  intofArg (nthArgListCn,  A}); 
getuidArg  (n.  A)  •>  procidofArg (nthArgListCn,  A)}; 
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gatfnArg  (n,  A)  ■>  fnof Arg(ntbArgList(n,  A)); 


193 


Contant  /•  kind  4  «/ 

/*  Tha  sort  Contant  is  spacific  to  this  application.  A  Contant  "is"  aithar  an 
Znt  (this  Bill  ba  tha  contant  of  a  ragistar)  or  a  nap  from  Int  to  Int  (which 
will  ba  tha  contant  of  a  aanory  block) .  •/ 

typaofContant  :  Contant  ->  Symbol 
ragContant  :  Contant  *>  Int 
blkContant  :  Contant  Int  ->  Int 
assignragContant  :  Int  ->  Contant 
assignblkContant  :  Contant  Int  Int  ->  Contant 
iaragContant  :  Contant  ->  Bool 
isblkContant  :  Contant  ->  Bool 

DISTINGUISHING  SET  typaof Contant  ragContant  blkContant; 
assignragContant  (n)  ■>  [’Ragistar,  n,  <m>  |->  arrint] ; 
isarrContant  (assignblkContant  (c,  n.  N))  •>  typaofContant(c)  •  'Ragistar; 
assignblkContant  (c,  n,  N)  ■> 

['Maablock.  arrint,  <m>  l->  if  than  N  alsa  blkContant (c, m)] ; 
isragContant  (e)  ■>  typaof Contant (c)  ■  'Ragistar; 
isblkContant  (c)  ■>  typaofContant(c)  ■  'Mamblock; 


Laval  /a  kind  4  */ 


/a  Tba  sort  Laval  is  particular  to  this  application.  It  is  assantially  the 
union  of  tha  sort  Symbol  «ith  a  ona-alamant  sat  (containing  syshi) .  The 
intant  is  to  hava  a  distinguishad  highast  Laval  and  a  salaction  of  other 
otharvisa  incomparable  Levels,  a/ 

aqLaval  :  Laval  Laval  ->  Bool 
syshi  :  ->  Laval 
mkLaval  :  Symbol  ->  Laval 
symof Laval  :  Laval  ->  Symbol 
issyshi  :  Laval  ->  Bool 

DISTIVGU1SBIH6  SET  issyshi  symof Laval; 

syshi  •>  [true .  arrSymbol] ; 

mkLaval  (s)  ■>  [falsa,  s] ; 

aqLaval  (11,  12}  •>  issyshi(ll)«issyshi(12)  t  symofLaval(ll)BsymofLavel(12) ; 
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RcgAssn  /*  kind  4  •/ 

/«  Thfl  sort  RsgAssn  is  spscific  to  this  application.  Its  function  is  to 
facilitata  tbs  dsfinition  of  slsasnts  of  sort  ComputsFn.  vhich  permit 
user  processes  to  do  computations  on  the  contents  of  the  registers  available 
to  them.  */ 

retrRegAssn  :  Int  RegAssn  ->  Znt 

procRegAssn  :  Process  ->  RegAssn 

DlSniGUISBZMG  SET  retrRegAssn; 

procRegAssn  (p)  ■>  C<b>  i'’>  regContantCcontofObJectCregofProcessCn.p)))] ; 
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ComputaFn  /«  kind  4  */ 


/»  We  have  defined  only  the  most  obvious  of  the  possible  elements  of  sort 
ComputeFn  here.  Clearly,  one  could  also  define  any  desired  arithmetic 
operations.  */ 

nameofComputeFn  :  ComputeFn  ->  Symbol 
evalComputeFn  :  ComputeFn  RegAssn  ->  Int 
selectComputeFn  :  Int  ->  ComputeFn 
constantComputoFn  :  Int  ->  ComputeFn 

DZSTIHGUISHIHG  SET  nameofComputeFn  evalComputeFn; 

selectComputeFn  (n)  «>  C  'select,  <R>  |->  retrRegA88n(n,R)  3; 

constantComputeFn  (n)  ■>  [  ’constant,  <R>  l->  n  ]; 
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SRM  /•  ■•cur*  rasourc*  aanagsr  */ 

opsofSRM  :  SRM  ->  SRMopSat 
stataofSRM  :  SRM  ->  Stats 
■chcdofSRM  :  SRM  ->  Schadular 
intarpofSRM  :  SRM  ->  Intarp 
polofSRM  :  SRM  ->  SacPol 

initSRM  :  SRMopSat  ObjactSat  ProcassSat  RaquastList  Schadular  Intarp  SacPol 
->  SRM 

naaraqSRM  :  Raquast  SRM  ->  SRM 
■tapSRN  :  SRM  ->  SRM 


SRM  Raquast  in  SRM  |•‘>  nawraqSRMCRaquast,  SRM) 

I  naxt  SRM  |->  stapSRMCSRM) 

/*  Not*  that  a  aariabla  can  pars*  as  an  SRM.  so  that  this  Binpla  gramaar  is 
not  usalass.  •/ 
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Rsquttst 


nullRsquest  :  ->  R«qu«8t 
opofRaquast  :  Raquast  ->  SRHop 
argsofRaquast  :  Raquast  ->  ArgList 
oktoRaquast  :  Raquast  Stata  ->  Bool 
procidofRaquast  :  Raquast  ->  Procassid 
■kRaquast  :  SRHop  ArgList  Procassid  ->  Raquast 


Raquast  : :■  Procassid  calls  SRHop  on  ArgList 

I ->  akRaquast (SRHop .ArgList .Procassid) 
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Procusid 


sysProcAssId  :  ->  Procaasld 
rnkusarProcaasId  :  Int  ->  Procassld 
typaofProcMald  :  Proe««sId  ->  Synbol 
intofProcAssId  :  Procasald  ->  Znt 
•qProcaaaZd  :  Procaasld  Procassld  ->  Bool 
pr*c*d«»Proc«BsId  :  Procaaald  Procaaald  ->  Bool 


Proeasald  uaar  Int  (->  akusarProcasaldClnt) 


SRMop 


namaSRMop  :  SRMop  ->  Symbol 

apSRMop  :  SRMop  State  ArgList  ->  Stata 

aqSRMop  :  SRMop  SRMop  >>  Bool 

MOop  :  •■>  SRMop 

okargaSRMop  :  SRMop  ArgList  ->  Bool 

uStora  :  ->  SRMop 

Store  :  ->  SRMop 

uConputa  :  ->  SRMop 

Co^>uta  :  ->  SRMop 

uFatcb  :  ->  SRMop 

Fetch  :  ->  SRMop 

uRaadX  :  ->  SRMop 

RaadX  :  ->  SRMop 

uWritaX  :  ->  SRMop 

Write!  :  ->  SRMop 

uRelease  :  >>  SRMop 

Purge  :  '■>  SRMop 

uGet  :  ->  SRMop 

Raise  :  ->  SRMop 

Get  :  *>  SRMop 

uSleep  :  ~>  SRMop 

Ssap  :  ■*>  SRMop 


SRMop  uStore  l->  uStoreO 
I  Store  l->  StoreO 
I  uCoapute  |->  uComputeO 
I  Compute  |->  Compute 0 
I  uFetcb  l->  uFetchO 
I  Fetch  l->  FetchO 
I  uReadX  l->  uReadXO 
I  RaadX  l->  ReadXO 
I  ttWriteX  !'>>  uWritaXO 
I  Write!  l->  Write! 0 
I  uRelease  |->  uReleaseO 
I  Purge  l->  PurgaO 
I  uGat  !•>  uGetO 
I  Raise  l->  RalseC) 

I  Get  |->  GetO 
I  uSleep  l->  uSlaepO 
I  Swap  |>>  SvapO 
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ArgList 


nilArgList  :  ->  ArgList 
nullArgList  :  ArgList  ->  Bool 
sppsndArgList  ;  Arg  ArgList  ->  ArgList 
hdArgList:  ArgList  ->  Arg 
tlArgList:  ArgList  ->  ArgList 
athArgList  :  Znt  ArgList  ->  Arg 
IsagthArgList  :  ArgList  ->  Xnt 


AUXILIARY  lOHTERMlIALS  I 

ArgList  nil  l->  nilArgListO 
I  I  l->  I 

X  Arg  l->  sppsadArgList (Arg. nilArgListO) 
I  X  ,  Arg  i'>  sppsndArgLlstCArg.X) 
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/ 


Arg 


objidtoArg  :  Objactld  ->  Arg 
procidtoArg  :  Processld  ->  Arg 
inttoArg  :  Int  ->  Arg 
fntoArg  :  Comput«Fn  ->  Arg 
objidofArg:  Arg  ->  0bj«ctld 
procidofArg:  Arg  ->  Proc«B8ld 
iatolArg  ;  Arg  ->  Int 
fnof Arg  :  Arg  ->  Coiq>ut«Fn 
gBtblkidArg  :  Int  ArgLiBt  ->  0bj«ctld 
gBtublkindArg  :  Int  ArgLlst  ->  Int 
g«toff8«tArg  :  Int  ArgList  ->  Int 
g«tr«gindArg  :  Int  ArgList  ->  Int 
gatuidArg  :  Int  ArgList  ->  Procsasid 
gstfnArg  :  Int  ArgList  ->  ConputsFn 


Arg  Int  |->  inttoArg(Int) 

I  Objsctid  l->  objidtoArg(Objsctld) 

I  Proesssid  |->  procidtoArg(ProcsssId) 
I  CoaputsFn  !•>  fntoArg(CoaputsFn) 
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7.8  High-level  description  of  simple  PLANNER 
progran 

state  Naaory,  Registers ,  Mbu,  RegX.  Uid.  UaitingUid 
begin  Neaory 

doStoreMeaCMeBoryin,  Kb,  Ml.  Rn,  Meaoryout)  ; 
doPurgeCMeaoryin,  Meaoryout)  ; 
doRaiseCMeaoryin,  Mb.  Meaoryout)  ; 
doGetCMeaoryin,  Mauin,  Kb.  MKUid.  Meaoryout,  Mauout) 

end; 

begin  Registers 

doFetehNeaCNeaeryin.  Mb,  Ml,  Bn.  Meaoryout)  ; 
doReadXCMeaoryin.  Mb.  Ml.  Maaeryout) 

end; 

begin  RegX 

dotfriteZCZin.  Vewalue,  Zout) 

end; 

begin  Mau 

doGetCMeaoryin,  Mauin,  Kb,  MMUid.  Meaoryout,  Mauout) 

end; 


begin  Uid 

doSvapCUidln,  UaitingUidIn.  UidOut,  WaitingUidOut) 

end; 

begin  WaitixigUid 

doSsapCUidIn,  UaitingUidIn .  UidOut,  UaitingUidOut) 
end 

operation  StoreCMb,  Nn.  Bn)  vitb 

state  MeaoryOut,  Begisters.  Mau,  RegX,  Uid.  UaitingUid 
produces  Meaory:  CCMpbys,  Mn.  undefined],  Ofpbys.  Mn,  Bevral]] 
by  deStoreMeaC  Meaory.  I^ys,  Rn,  Bewral.  MeaoryOut) 
with 

praeond  fetehReg (Registers.  Uid.  Rn,  lewal) 
trigger  Register 

difference  CCC^id,  Rn,  undefined],  CUid,  Rn,  levral]] 

end  : 

precond  aeaMapCRau.  Uid,  Rphys,  Mb) 
trigger  User 

difference  CCUid] .  [UaitingUid]] 
end 


204 


•nd; 


oparation  FatcbCMb,  Nn.  Rn)  vith 

■tata  Manor;,  RagistarsOut ,  Mnu,  RagX,  Uid,  UaitingUid 
producas  Ragistars:  [[Uaar,  Ra,  undafinad]  ,  [Usar,  Rn,  Nawal]] 
by  doStoraRagC  Ragistars,  Usar,  Rn,  Nawal,  RagistarsOut) 
vith 


pracond  aquaI(Uid,  Usar) 
triggar  Uid 

diffaranca  CrUidJ,  [WaitisgUid]] 

and  : 

pracond  doFatchManCNanory.  Mphys,  Mn,  Nawal) 
triggar  Manor; 

difiaranca  [[Mphys,  Mn,  undafinad],  [Mphys,  Mn,  Nawal]] 

and  : 

pracond  nanMapCMnu,  Usar,  Mphys,  Mb) 
triggar  Uid 

diffaranca  [[Uid] ,  [UaitingUid]] 
and 


and; 

oparation  RaadXCMb,  Mn)  vith 

stata  ManoryOut,  Ragistars,  Mnu,  Xout,  Uid,  UaitingUid 
producas  Manor;:  [[Mphys,  Mn,  undafinad],  [Mphys,  Mn,  lout]] 
by  doStoraManC  Manor;,  Mphys,  Mn,  lout,  ManoryOut) 
vith 

pracond  aqualCRagl,  Xout) 
triggar  RagX 

diffaranca  [[RagX] ,  [Xout]] 
and 

and 

and 
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8  Axiomatic  Verification  of  Concurrency  in  SR 

In  the  two-tier  methodology  that  we  are  developing,  the  axiomatic  tier  provides  the  means  to 
perform  concrete  verification  of  the  correctness  of  actual  running  implementations.  In  this  regard, 
our  methodology  is  more  complete  that  the  methodologies  presented  in  the  cwent  literature,  in  that 
the  majority  of  current  researchers  are  focusing  solely  on  the  level  of  specification  of  concurrency, 
with  no  solid  links  to  operational  code. 

The  foundation  necessary  to  veri^  operational  code  is  the  formal  semantics  of  an  operational 
programming  language.  The  next  two  subsections  present  our  currat  work  on  buil^g  this  founda¬ 
tion  for  the  SR  programming  language.  The  first  subsection  describes  the  syntactic  enhancements 
that  are  currently  being  added  to  the  SR  language  to  support  verification.  The  second  subsection 
then  outlines  our  most  cnrrent  version  of  the  axiomatic  semantics  of  SR.  These  semantics  provide 
the  basis  for  ccnnpleting  our  two-tiered  methodology. 
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8.1  The  Syntax  of  Annotated  SR 
SYSTEM 


system 

systemcomp 

globidcom 

globildecl 

rescomp 

sepspec 

specMadbody 

sepbody 

ibstnctspee 

eoncretespec 

speccompUst 

speccomp 

import  clause 

ezteodclause 

resbody 

bodycomp 

initiil 

£nil 

block 

blockcomp 

dec! 


(  systemcomp  1 1  )  • 

globslcomp  I  rescomp  |  blockcomp  |  sysinvariants 
“global”  id  (  globsldecl  //  )•  “end”  [  id  ] 

constdecl  |  typedeci  |  optypedecl 
MbstrACtspec  sepspec  |  specAudbody  \  sepbody 
coDcretespec  “separate” 
coacretespec  resbody  “end”  {  “id”  ] 

“body"  id  resbody  “end”  (  “id”  ] 

“resource”  id  speccompUst  “end”  [  id  ] 

“resource”  id  (  speccompUst  “body”  id  ]  “(”  (  parmspec  //  “;”  )•  “)” 
(  speccomp  //  “;”  )* 

importciause  |  exteadclause  |  operdecl  |  constdecl  |  typedeci  | 
optypedecl  |  EQNDRCL  |  SPECRRSTR  |  RESINVARIANT  I  SPECVARDECL 
“import”  ( id  1 1  “»”  )• 

“extend”  (  id  1 1  “,”  )* 

{bodycomp  //  “;”)•  “end”  [  id  ] 

initial  |  Unal  |  procdecl  \  processdecl  \  importciause  \  dec] 

“initial”  block  “end”  [  “initial”  ] 

“flnsJ”  block  “end"  (  “final”  ] 

(  blockcomp  “;”  )  • 
dec!  I  stmt  |  importciause 

typedeci  |  constdecl  |  vardecl  |  optypedecl  |  operdecl 


TYPES 


typedesig 

typedeci 

typedefa 

typerestr 

eaoffldefii 

striagdelh 

recorddefn 

ptrdefh 

capdefh 


typedefa  |  var 

“type"  id  “=”  typedefa  [  typerestr  ] 

eaumdefa  |  stringdefa  \  recorddeia  |  ptrdefn  \  capdefa 

“{  pubUc  }”  I  “{  private  }" 

“enum”  “(”  (  id  //  “,”  )  •  “)” 

“string”  “("  expr  “)”  )  “string  (  *  )  ” 

“rec”  “("  (  UainitVar  !/“,”]  “)* 

“ptr”  typ^esgi 

“cap”  war  |  “cap”  operspec 
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DECLARATIONS 

varded 

•*s 

“var"  (  vardefa  // 

coBstdecl 

"const”  (  lojtvar  // 

nrde/a 

iaitvar  |  uxuzutvar 

isitvar 

::s 

varaame  ezpr  |  varname  typedesig  expr 

uainitvar 

(  varname  //  )■*■  ^edesjg 

varsame 

::s 

id  1  id  gabseripts 

$ubieripts 

*1"  range  “J"  |  range  range  “]" 

nage 

expr  1  expr  expr  |  |  eacpr  |  expr  *” 

SYSINVAUANTS 

::s 

POXUULA  * 

KBSIKVAUANT 

::s 

POUIULA  * 

■QHDBCL 

::s 

"eqn"  (  “let"  {  varded  —  constded  ]]  (sQuatIOM;)*  “nqe" 

SPBCBXSTK 

OXNBXATOXS  |  PAtTITlONS  |  COMSSQVBMCXS  |  BXEUPTS 

SPSCVAADCCL 

::s 

varded 

OPS,  PROCS,  etc 

optypedecl 

“optype"  id  [  ]  operspec 

operded 

operelggg  opemame  openpee  |  operdess  opemame  id 

operclass 

“op”  1  "external” 

operaame 

::s 

id  1  id  sobsenpts 

openpee 

“(*  ( Pannspec  //  “j”  ]  “)"  (  retomspec  ]  [lospsc  ]  oprestr 

pantupee 

[  panakiad }  oainitvar 

retunupee 

::s 

“returns”  varaame  typedesig 

oprestr 

•*«s» 

“[  call  ]"  1  “[  send  ]”  |  “[  call  ,  send  ]”  |  “[  send  ,  call  ]” 

pMmkiad 

“var"  1  “v^”  1  “res”  |  “rer 

procded 

“proc”  id  “(”  ( id  //  ]  “)”  I  “returns”  id  )  block  “end”  [  id  ] 

proceudecl 

::?= 

“process”  id  block  “end”  [  id  ] 

lOSPBC 

PKX  1  POST  1  LIVE  1  PAIX  |  EXIIES  |  GOAKANTEES 

STATEMENTS 

itmt 

geggtmt  1  interstmt 

•eqitmt 

::s 

gkipgtmt  1  stopstfflt  1  gggttgtmt  |  gwapgtmt  |  iacstmt  |  decstmt 
J&tmt  1  dogtmt  1  foreUatmt  I  exitatmt  I  aextgtmt  I  assert 

$kip$tmt 

::s 

“skip" 

ftopatmt 

::s 

“stop"  [  ea'tcode  ] 

ezitcode 

::s 

“("  expr  “)" 

atgnstmt 

::s 

var  “:a:"  expr 

iacftxDt 

P»r"++" 

decrtmt 

::s 

var  * 

twBpgtmt 

**Sp 

var  “:as:"  var 

i&tmt 

“ir  gaardedaad  “11"  |  “H”  gnardedemd  ifstmtl  “fi” 

Uktmtl 

•  ••• 

“Q”  gaardedaad  |  “Q"  gnardedemd  i£itmtl  |  elsecmd 

doctfflt 

“do"  gnardedemd  *od"  |  “do"  gnardedemd  dostmtl  "od" 

doftmtl 

::3s 

“D”  gnardedemd  |  “Q"  gnardedemd  doetmt]  |  “Q”  elsecmd 
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gu«rdedcmd 

elsecmd 

forallstmt 

exitcmd 

nextcmd 

quiuit 

direction 

interstmt 

invocstmt 

cnlUtmt 

eeadttmt 

implstmt 

inputitmt 

leceiveftmt 

retanutmt 

replystmt 

GBNBBATOas 

PARTITIONS 

Operand 

operguud 

interquant 

opeiindication 

opembeaipts 

iyacexpt 

sebedexpr 

reecontroistznt 

aeatestint 

iocation 

destroyatmt 

eoneatmt 

concand 

condnvoc 

poatproc 

EXPRESSIONS 

PORlfULA 

expr 

orexpr 

aadexpr 

ndescpr 

abfexpr 

addaxpr 

mulexpr 

aimpleexpr 


expr  >"  bJodc 
“else  -  >”  block 

“fa"  (  quant  //  >”  block  “£a” 

“exit" 

“next" 

id  ei^r  direction  expr  [  “it"  expr  ] 

“to"  I  “downto” 

invocstmt  |  implstmt  |  rescontrolstmt  \  concstmt 
caJlatmt  |  aendstmt 
var  I  “call”  var 
“send"  var 

inputitmt  I  receiveitmt  |  retamstmt  \  replyatmt 
“in"  (  operand  //  “Q"  )  “ni" 

“receive"  operindication  “("  [  var  //  “,"  )  “)" 

“return" 

“reply” 

operapec  “generated  by"  ??? 
operapec  “partitioned  by"  ??? 

[  interquant  ]  operguxrd  [  acbedexpr  ]  “-  >”  block 

operindicntion  “("  [  id  //  “,"  ]  “)”  [  “returns"  id  ]  [  ayncexpr  ] 

“(”  (  quant  //  “,"  )  “)” 

id  I  id  operaubacripta 

“["  expr  “]"  1  “I"  expr  “,"  expr  “]” 

“and"  expr 
“by"  expr 

createitmt  |  deatryatmt 

var  “;=  create”  id  “("  [  expr  //  )  “)”  [  iocation  ] 

“on”  var 
“destroy"  var 

“co"  (  conccmd  //  “//”  )  “oc” 

[  interquant  ]  condnvoc  [  poatproc  ] 
eellatmt  |  eagnatmt 
“-  >"  block 


expr  /*  Evaluate  with  set  operators  on  specvars  */ 

opexp  [  orop  expr  ] 

andexpr  [  andop  orexpr  ] 

relexpr  [  reiop  end  expr  ] 

abfexpr  [  shfop  ralexpr  ] 

addexpr  [  sddop  abfexpr  ] 

mulexpr  {  muiop  addexpr  ] 

[  onop  ]  aimpleexpr 
JiteraJ  |  var  |  amyaggr 
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HYPER  LITERALS 

Amyiggr 

;= 

“("  (  vectorelem  //  )  “)” 

vectorelew 

[  “("  expr  “]"  ]  expr 

LITERALS 

:= 

number  |  stnngliteral  |  “true"  |  “false”  |  “null"  |  “noop” 

VARIABLES 

vu 

s 

objnnmelist  [  nrgs  ] 

objutmelist 

= 

(  objnnme  j  f  ) 

objBtme 

= 

id  indices  *  |  id  • 

xadides 

“("  expr  “]"  1  slice  |  “[”  expr  expr  “]”  |  “["  expr  slice 

“("  slice  expr  “]” 

slice 

:= 

expr  expr  |  expr  “:  *”  |  “*  expr 

*rgs 

;= 

“(”  [  expr  //  ]  “)” 

OPERATORS 

uaop 

s 

“-"  1  “  "  1  “not"  1  “O”  1  “?" 

mulop 

s 

1  “/"  1 

*ddop 

s 

sbfop 

S 

“<<"  1  “»" 

relop 

s 

“="  1  “!  ="  1  “  =”  (  “>=”  1  “>”  1  “<=”  1  “<"  1  “and"  1 

crop 

= 

“or”  1  “1"  1  “xor” 
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8.2  The  Axiomatic  Semantics  of  SR 

operation  invocation 


call_statenient 


<  b,p>  {P  I  caU  op_dcnotation  (aaual)  {R} 


send  statement 


<  b,p>  (P  I  *end  op_denotatioD  (aaual)  (P) 

where  aaual  =  «  (val_args.  res_args.  var_args) 

P  is  the  precondition  of  a  c^send 
P’  is  used  in  satisfaaion  proof 


•  evaluating  the  argument  expressions 

•  serviced  by  a  proc  create  new  process 

•  serviced  by  an  input  statement  -»  queue  the  invocation 

•  invocations  of  the  same  operation  by  the  same  invoking  process  are  queued  in  the  order 
they  are  invoked. 

•  A  call  statement  terminates  when  the  operation  has  been  serviced  and  results  have 
been  raumed 

•  A  send  statement  terminates  when  a  service  process  has  been  created  or  when  the  argu¬ 
ments  have  been  queued. 
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proc 


proc  oper  (in_fonnal)  returns  result  S  end 
input_statement 

in  cpi  Gn_fonnal)  returns  resulti  and  Bi  by  E,  -4  S,  Q*'  ni 

•  glass  ■  operations  implemented  by  the  same  input  statement 

•  For  a  given  class,  at  most  one  process  at  a  time  can  be  selecting  an  invocation  to  sa- 
vice  or  appending  a  new  invocation.  The  access  is  in  FCFS  order. 

•  input  statement  delays  the  executing  process  until  some  mvocaticm  is  seleaable 

•  an  invocation  is  selectable  if  the  boolean-valued  synchronization  expression  in  the 
corresponding  operation  guards  is  true 

•  no  scheduling  expression  the  oldest  selectable  invocation  is  serviced 

•  scheduling  expression  the  oldest  seleaable  that  also  minimizes  the  scheduling 
expression  is  serviced 

•  both  synchronization  and  scheduling  expression  can  reference  invocation  arguments 

•  termination:  the  seleaed  block  terminates,  raum  is  executed,  or  exit/ next  is  executed 
(if  input  statement  is  within  an  iterative  statement) 

•  results  are  raumed  to  the  caller  when  the  input  statement  terminates  or  vdien  a  reply 
statement  is  executed 

•  reply/  raum  is  associated  with  a  smallest  enclosing  input  statement  or  proc 

•  a  process  that  executes  reply  continues  executing  with  the  statemem  following  rq>ly. 

bi  request(time)  and  free  by  time  -4  free :«  false 
Q  releaseO  free  :*  true 
ni 
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(Q)  proc  oper  (in_fonnal)  returns  result  (T}  S  (X)  end  (W} 


{Q)  in  opi  (in_fonnal)  returns  result^  and  5,  by  £,  {T, )  5,  {X, }  [f  ni  (W) 

(U)  or  {Ui }  is  assertion  about  invocation’s  termination 


proc 

«  b.p>  S  {X)  /N  -r  aux)  -»  (X  -♦  U). 

V  jjt  :  (<  jjc>  {V}  reply  {VT  /v  k*  p  /n  'r  aux)  (V  u;^, 

V  :  (<  j*>  {V}  return  {false}  a  k=  p  a  ‘r  aux)  CV  -»  a  X)) 


<  b.p>  (Q)  proc  oper  (in_lbrmal)  returns  result  S  end  {W} 


input_statement 

V  i  :  X,  -»  W. 

«  (T'i  I  Ti}^‘  )  Si  (X.  )  A  (X.  -*  Ui), 

V  jJt  :  (<  jjc>  (V)  reply  (V)  a  k»  p,-  t\'rjmxi)  -»  (V  -+  Vil^‘), 

V  jJt  :  (<  jjc>  (V)  return  {false}  a  k=  Pi  f\  ~  r  auxi  (y  (Ui  X,  )), 

V  jJt  :  (<  j4c>  {V}  next  {false}  a  js  b  a  “r^auxi)  -♦  (V  -*  I/.  ), 

V  jX  :  (<  jjc>  {V}  exit  {false}  A  js  b  A  "rjtuXi)  (V  -»  f/,) 


<  b.p>  {Q}  in  operi  (in_fonnal)  returns  resuUi  and  B,  by  £,  -*  Si  {T  ni  {W} 
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RPC  rule 


*  Satisfaction  proof 

For  every  call  c  and  matching  proc  (including  process),  prove  Sat^  (c.proc)  valid. 
SaXrpc  (c,proc): 

P  -*  P* 

/S  (Q  A  P)  -♦ 

A(UAPO-»R-j-Sri«r'^ 

A(P'AX)-*W 

*  Nottiaterfcrcnec  Proof 

For  every  assignment  statement  S  and  assertion  I  paralld  to  S.  prove 
(SJ)  vaUd. 

NIrpc  (S.  I):  ■ 

{IApre(S)l  S  (I) 

For  every  call  c  and  matching  proc  and  every  assertion  I  parallel  to  both  c  and 
proc,  prove  NI^Sat,pe  (c,procJ)  valid. 

NlJSai,^  (c.  proc,  1): 

a  A  Q  A  P)  _»  /\  a  A  p*  A  U) 

For  every  assignment  statement  S  of  proc,  and  assertion  I  in  proc  that  references 
global  variables,  prove  (S  J): 

Nl^f  (S.  I): 

(IAprc(S)I  S  {1} 
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Rendezvous  rule 


*  Satisfactioii  proof 

For  every  call  c  and  matching  opi  of  input  statement,  and  every  opj  of  the  same 
input  statement,  prove  Sat,^  (c/>pi)  valid. 

Satmdn  (.c,opi): 

(P  /\  -k)clt(/»endmg*i«(,^)))  -♦ 

(Q  P  10Clt(Peildingg^(j|Pj))) 

/\  (Q  /\  p  /\  lod^(Pendingc^^^gp^^))  -»  false 

/\  (7” j  /\  C) 

UckfPtKdiHt^  ^ 

/\  (7 .  /\  -  C)  -♦  C/^ 

/V  (P*  /\  £/i)  ‘ 

/\  (P’/\X,)-»  W 

m 

Where  C»  ^ 

A  Cir  inv\opi) :  B, i,  ^ -♦  posCmv ’(<??,))>  posOnv(opi)) 

-yom./,, 

V  (£ii,  *  Eimjaa.CU,^’^  posOnvXopi))>  posCmv((^i )))) 

■I  Jarma!^ 

f\  (V  inviopj) :  pos(inv(opj ))<  posCtnvfop;))  -»  ) 

*  NontaitcrfercBcc  Proof 

For  every  assignment  statement  S  and  assertion  1  paralld  to  S,  prove  Af/m^fSJ) 
valid. 

(S4):  {I  /V  pre(S))  S  {!) 


For  every  call  c  and  matching  opcr  of  input  statement  and  every  assertion  I  parallel 
to  both  c  and  opcr.  prove  Nl^Sat,^  (c,  operj)  valid. 

NlJtUrnd^  (C.0perj): 

in  farmal-  am  aaaal^^  jaiali  . 

(I  Q  A  P)  _  ''  a ''  r-  At;,)-.  ‘ 
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Dynamic  process  creation  rule 

*  Satisfaction  proof 

For  every  send  s  and  matching  proc  (including  process),  prove  Satp,oc  (s.proc) 

valid. 

Satfroe  (s.proc): 

p  p*  /\  (P  /\  Q)  -»  A  X  -»  W 

*  Nonintcrfcrcacc  Proof 

For  every  assignment  and  send  statement  S  and  every  assertitm  I  parallel  to  S. 
prove  NIp^  (SJ)  valid. 

NI^  (SJ):  {I  /N  pre(S))  S  (I) 

For  every  proc/ process  heading  S  and  every  assertion  I  parallel  to  S,  prove 
Nljat^  (SJ)  valid. 

Nljat^  (S,D:  a  prc(S)) 

For  every  assignment  statement  S  of  proc,  and  assertion  I  in  proc  that  references 
global  variables,  prove  ffl^f  (S  J): 

NI„,f  (S.  I): 

{lApre(S))  S  {!) 


216 


Message  passing  rule 


*  Satisfaction  proof 

For  every  send  s  and  matching  op^  of  input  statement,  and  every  opj  of  the  same 
input  statement,  prove  SoXauf  (s.opi)  valid. 

Sax^t  (s.  op, ): 


(P  -k)ck(/*«iidi#igd«(^.)))  -♦ 

/\  (Q  l\  10Ck(Feildwigj/^((p.)))  — ♦  7*,- 


/\  (Q  /\  lock(Fendi>igej^(^.)))  -♦  false 
(T  i  C)  i 

/\  (P’'\  X,)  -»  w 


where 

m  Jmm^- 
—  P  * 


m  JtrmS 

A  (V  inv'Copi) :  B i  -*  pos(inv’(<?7i))>  posCmv(op,  )) 

m  Jormal  in  Jormat  m 

ifi  f  in 

^  I>os(inv’(<y,)>  pos(mv(<?7.  )))) 

m  Jormal^ 

f\  (V  inviopj) :  pos(inv(opy ))<  pos(inv(op, ))  -»  ) 


*  Noaiateifereace  Proof 

For  every  assignment  and  md  statement  S  and  every  assertion  I  parallel  to  S. 
prove  Af/auf  (SJ)  valid. 

NI,u,  (SJ):  {I  pre(S)l  S  {!) 

For  every  operation  indication  or  receive  S  and  every  assertion  I  parallel  to  S. 
prove  Af/_5ara„j(SJ)  valid. 

Nljat,^  (SJ):  a  pre(S))  -♦ 
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number  assignment  rule 


Each  statement  is  attached  with  two  sequence  numbers  delimited  by  <  >  .  b  and  p 
are  rvalues.  b_aux  and  p_aux  arc  auxiliary  variables  of  type  int,  r_aux  is  auxiliary  vari¬ 
able  of  type  bool. 


<  b,p>  S 


<  b,p>  :  <  b_aux+  +  ,p>  ;  <  b4»  Sj 

i^ere  S  ■  S|;  8^,8^ 

8 1  and  53  are  not  one  of  the  following:  do.  fit.  and  co 
52  is  one  of  the  following:  do.  fa.  or  oo. 


<  b.p>  if  Bj  -»  5j  [T  fi 

<  b.p>  if  Bj  -»  <  b4)>  5,  IT  fi 

<  b^>  do  B,  -*  5j  [T  od 

<  b.p>  do  B,  -4  <  b.p>  5i  or  od 
where  y  »  Xj  ^  ...  x, 

proc  oper  (formal)  returns  arg  S  end 

proc  oper  (formal)  returns  arg  <  b_aux+  + .  p_aux+  +  >  S  end 
process  oper  S  end 

process  oper  <  b_aux44 ,  p_aux4 4  >  S  end 

<  b^>  in  oper,  (formali)  returns  r,  and  Bi  by  exprj  5,-  [T  ni 

<  b4»  in  oper,  (formali)  returns  r,  and  Bj  by  expri  -» 

<  b4>_aux++>  5j  (T  ni 
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if  statement 


<  b.p>  {P  A  B, }  5.  {Q). 
(P  A  Q 


<  b.p>  {P)ifBi  -♦  Si  [f  fi  (Q) 


<b.p>  {PABi)S,  IQ}. 
<b.p>  IP  a-bB)S,  IQ) 


<  b,p>  IP}  if  B,  -»  S,  [T  else  -»  S,  fi  |Q} 

wbereBi  >  |B].  Bj  •  “  1 ) 

BB»  B,  V  B2^  B,., 


do  statement 


<  b.p>  II  A  B. )  s,  |I}. 

V  j Jc  :  (<  jjc>  IR)  exit  |false}  a  j=  b)  -»  (R  Q), 

'rf  j Jc :  (<  jjc>  |R)  next  {false}  a  jts  b)  ^  I) 


<  b,p>  a)  do  B.  -*  S,  IT  od  Id  A  -BB)  V  Q} 


where  B^  «  |B  j,  B  2. ....  B,  « j } 
BB  ■  B,  V  ...'^  B,., 


compound  statement 


<  bi4>i>  IP)  Si  IR). 

<  B2^3>  |R}  S2  IQ} 


<  bij>i>  IP}  S,;  <  B2^2>  S2  IQ} 
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9  Working  Examples  and  Models 

9.1  A  Secure  Network  Mail  System  Model 

9.1.1  Introduction 

A  mail  system  is  secure  if  it  can  protect  m^  from  nnanthorised  access,  nnautkorized  modification 
or  onauthorized  disclosure.  Tliis  section  proposes  a  secure  network  mail  system  to  accomplish  this 
goal.  The  proposed  model  is  independent  of  the  techniques  used  to  implement  the  system.  The 
model  is  based  on  the  network  mail  system  described  by  Owicki  [OwiSO],  and  on  the  secure  military 
message  systems  proposed  by  Landwehr  et  al  (LE*84]. 

The  Owicki  network  mail  system  [OwiSO]  has  a  zing  structure.  Each  server  consists  of  three 
processes  and  three  buffers.  An  incoming  message  from  a  neighboring  node  is  read  by  the  read 
process;  the  message  and  all  other  messages  sent  by  local  users  axe  stored  in  the  switch  buffer. 
The  switch  process  then  retrieves  messages  from  the  switch  buffer  and  deposits  them  into  either 
the  output  buffer  or  the  user  buffer  depending  on  the  destination  of  the  mail.  The  output  process 
will  read  message  from  the  output  buffer  and  forward  it  to  the  next  node.  Local  users  receive  mail 
from  the  user  buffer.  The  system  assumes  that  all  meuages  sent  out  by  a  node  are  guaranteed  to 
be  received  by  the  neighboring  node.  No  security  is  imposed  on  the  system  except  that  messages 
are  only  delivered  to  the  correct  receivers.  However,  the  system  does  guarai.  .ee  delivery  as  long  as 
the  number  of  undelivered  messages  is  lest  than  the  number  of  messages  in  the  switch  buffer  and 
the  output  buffer. 

The  Landwehr  secure  military  message  systems  model  [LH*84]  supports  arbitrary  network 
eonacction  and  captures  the  security  policy  that  a  military  message  system  must  enforce.  The 
model  describes  multilevel  secure  systems  that  protect  information  of  different  classifications  from 
users  with  different  clearances.  An  object  is  a  single-level  unit  of  information  and  a  container  is  a 
multilevel  information  structure.  In  general,  a  message  is  a  container.  In  this  model,  a  user  may 
display,  update,  create,  delete  or  release  a  message.  Security  is  enforced  by  the  system.  Only  an 
authenticated  user  may  log  in  the  system,  i.e.,  by  presenting  a  unique  user  ID  and  by  passing  the 
system  authentication  check.  Once  entering  the  system,  a  user  may  invoke  an  authorized  operation, 
and  may  access  to  information  that  has  passed  the  system’s  flow  control  check.  For  example,  a 
user  can  view  an  entity  with  a  classification  less  than  or  equal  to  the  user’s  clearance  and  the 
classification  of  the  output  medium. 

As  noted  in  the  introduction,  the  proposed  architecture  of  each  server  in  the  mail  systepi  is 
similar  to  the  Owicki  mail  server  [OwiSO],  and  the  security  model  is  derived  from  the  security  model 
of  [LH*84],  (LS86]. 

9.1.2  Ovemll  Doecription 

The  proposed  network  maQ  system  model  supports  arbitrary  network  connection  and  is  a  multilevel 
secure  system  model.  Each  node  has  one  server  with  five  processes  and  three  buffers.  The  five 
processes  are  send,  accept,  switch,  retrieve,  and  forward  processes.  The  names  of  three  buffers  are 
switch  buffer,  local  buffer  and  forward  buffer  (see  Figure  1).  Each  process  is  assigned  to  top  security 
clearance.  Each  buffer  is  a  multilevel  information  structure  and  stores  mail  that  is  processed  by 
the  server.  A  mail  is  a  single-level  unit  and  consists  of  two  parts:  a  header  and  text.  A  mail  header 
contains  sender  ID,  receiver  ID,  classification  of  the  mail  and  timestamp  that  records  when  the 
mail  is  entered  the  system. 

Each  user  and  node  are  assumed  to  have  a  unique  ID  in  the  network.  It  is  farther  assumed 
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tocftl  UMT  U 


CS(T)  <-CL(U) 

T»Ud  pMVwd 


itfauMl  T 


MiCbbor  ood«  N 


CS(M)-CSL(U)<-CL(U} 
CSUS)  CSLHJ) 
S«Mi«rlD(M)-Uirn> 


CSL(A)-CSUF^) 


CSUS}  <-CS(SB) 


CSL(A)  <-CS(SB) 
4iaypud  >u3 


CS(V)  <-CSL(SW) 


CS(M)<-CSL(R) 

4  lUctivtrlD  •UairlD 

CSL(R)  -  csyoi  <- CU(U) 
CSL(R)<-CS(T) 


csysw)  <-cs(rB) 

Nad<{M)  <>  S«nni 


■orwwd  baSnr  FB 


CS(M)  <-CSl(r) 


tarmiul  T 


CSL(r)-CSl<A,) 
osTpud  mail 


CS(T)<-Ct(U) 

valid  liMiiid 
rU 


NOTE:  M^UaU 


Figore  1:  Mail  Server  Architecture 
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th»t  &  node  knows  how  to  forward  mail  to  the  proper  destination,  that  all  server  processes  can  be 
trusted  and  that  connections  of  network  devices  are  secure.  A  user  may  send,  retrieve,  or  save  mail. 
However,  sending  and  retrieving  mail  must  be  performed  by  the  mail  server  on  user’s  behalf. 

Security  is  enforced  by  the  system  and  consists  of  three  parts:  access  control,  flow  control,  and 
privacy  and  integrity  control.  Access  control  prevents  unauthorized  access  to  an  entity  connected 
to  the  network.  Only  authorized  users  may  login  the  system,  and  only  authorized  server  processes 
may  read  or  write  into  server  buflfers.  Flow  control  prevents  unauthorized  dissemination  of  mail 
stored  in  a  buffer.  A  user  may  not  read  mail  which  has  higher  classification  than  the  clearance  of 
the  setting.  Privacy  and  integrity  control  prevents  unauthorized  disclosure  or  modification  of  mail 
that  are  being  transmitted  between  nodes.  This  is  to  deter  an  eavesdropper  from  intercepting  mail. 

Q.1.S  The  Model 

In  order  to  describe  the  model  in  details,  first  of  aU,  we  present  the  definitions  of  terms  used.  Then 
we  describe  user’s  operations.  Finally,  we  describe  roles  of  server  processes.  Security  issues  are 
discussed  as  parts  of  each  descriptions. 

Definitions  The  following  terms  are  used  in  this  model  and  their  definitions  are  provided  as  a 
basis  for  the  model. 

•  Entity  --  a  network  resource  (device,  file,  m^,  server  process,  server  buffer)  or  a  legitimate 
user. 

•  Object-!^  passive  entity  that  is  acted  upon  by  another  entity.  An  object  may  be  a  device,  a 
mail  message,  or  a  buffer. 

•  Mail  -  a  ringle>level  unit  of  information.  A  mail  message  contains  a  header  and  text. 

•  Clastifieation  -  a  security  level  attached  to  an  object.  A  classification  includes  a  sensitivity 
level  and  set  of  compartments. 

•  Buffer  -  a  multi-level  information  unit  containing  mail. 

•  Subject  -  a  subject  may  be  a  user  or  a  server  process  acting  on  behalf  of  a  user. 

•  ID-  identifier.  A  string  of  characters  names  a  unique  entity. 

•  Clearance  -  a  degree  of  trust  associated  with  a  subject. 

•  Current  Seeurity  Level-  the  clearance  of  a  subject  that  is  currently  being  recognized.  It  must 
be  less  than  or  equal  to  the  clearance  of  the  subject. 

Description  of  User  Operations  Login:  A  user  can  gain  access  to  the  mail  system  only  by 
logging  in.  In  order  to  lo(^,  the  user  provides  a  user  ID  and  a  password.  The  system  will 
authenticate  the  information  provided  by  the  user,  the  login  process  completed  successfully  only  if 
and  when  the  system  recognized  the  user  as  a  legitimate  subject  and  the  clearance  of  the  user  is 
higher  than  or  equal  to  the  classification  of  the  terminal  that  the  user  is  using. 

Send  request:  After  a  successful  login,  a  user  may  compose  a  mail  message.  The  user  selects  a 
current  security  level  that  must  be  equal  to  or  less  than  the  maximum  clearance  of  the  user.  The 
clearance  of  the  server  is  set  to  a  level  equal  to  the  current  security  level  and  the  created  message 
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will  be  clucified  &t  the  tame  level.  The  user  then  enters  the  receiver  ID  and  text.  If  the  text  is 
from  a  file,  the  classification  of  the  file  must  be  less  than  or  equal  to  the  CTirrent  security  level  of 
the  user. 

Retrieve  request:  A  user  must  first  login  the  system.  After  a  successful  login,  the  user  selects 
a  current  security  level  and  requests  server  to  retrieve  mail.  A  mail  message  may  only  be  displayed 
on  a  terminal  if  the  message  is  intended  for  the  user  and  the  clearance  of  the  terminal  is  higher 
than  or  equal  to  the  classification  of  the  mail. 

Save  request:  The  retrieved  mail  will  be  saved  as  a  file  and  the  file  is  classified  at  the  same 
level  as  the  m^. 

Description  of  Server  Processes  Send  process:  When  a  user  enters  a  send  mail  request,  the 
server’s  send  process  sets  its  clearance  to  the  current  security  level  of  the  user.  Before  a  mail 
message  can  be  admitted  into  the  network,  the  send  process  timestamps  the  message  and  deposits 
it  into  the  switch  buffer. 

Accept  process:  In  order  to  receive  m^  from  a  neighboring  node,  the  clearance  of  the  accept 
process  must  be  equal  to  the  clearance  of  the  forward  process  of  the  neighboring  node.  The  accept 
process  will  decrypt  the  received  mail  (link  to  link  decryption)  and  then  deposit  the  received  mall 
into  the  switch  buffer. 

Svritch  process:  The  switch  process  reads  mail  from  the  switch  buffer  and  deposits  it  into  either 
the  local  buffer  or  the  forward  buffer  depending  on  the  destination  of  the  mail.  The  local  buffer 
contains  mail  intended  for  local  users  and  the  forward  buffer  contains  mail  intended  for  users  of 
other  nodes. 

Retrieve  process:  The  retrieve  sets  its  clearance  to  the  current  security  level  of  the  user,  and 
reads  mail  from  the  local  buffer  on  user’s  behalf.  The  retrieve  process  may  only  read  mail  that  is 
intended  for  the  user  and  have  a  classification  less  than  or  equal  to  the  clearance  of  the  retrieve 
process. 

Forward  process:  The  forward  process  reads  mail  from  the  forward  buffer,  determines  the  next 
node  to  be  routed  and  establishes  connection  with  the  accept  process  of  that  node.  Before  trans¬ 
mitting  the  mail  to  the  next  node,  the  forward  process  encrypts  the  mail.  The  current  security  level 
of  the  forward  process  and  the  accept  process  must  be  equal  in  order  to  establish  the  connection. 

Note  that  send  process  and  retrieve  process  are  parts  of  the  send  request  and  retrieve  request 
operations  described  below.  The  reason  is  that  the  server  executes  these  operations  on  user’s  behalf. 

9.1.4  Security  Specification 

This  section  describes  the  security  assumptions,  the  security  assertions  and  the  security  require¬ 
ments  of  the  proposed  model.  The  security  assumptions  contains  rules  that  are  beyond  mail  server’s 
control. 

Security  Assumptions  User  behavior  assumptions: 

a.  The  Network  Security  Officer  assigns  clearances,  device  classification  properly. 

b.  Sender  selects  a  correct  current  security  level  when  sending  mail. 

c.  User  with  higher  security  clearance  may  know  the  security  level  of  user  with  lower  clearance, 
but  not  vice  versa. 

d.  User  will  follow  the  established  security  r^ulation. 

Network/Server  behavior  assumptions: 
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•erver: 

«.  login  secure 

CSCT)  <•  CLCU) 

▼alid  authantication 

b.  reclassify  secure:  to  let  aurent  lecuzity  level  of  a  subject. 

CSL(U)  <-  CL(U) 

c.  send  secure 

CSL(U)  <-  CLCU) 

CS(N)  •  CSLCU) 

CSLCS)  •  CSLCU) 

•andarlO  ■  uaarlD 

d.  retrieve  secure 

CSL(R)  •  CSLCU) 

CSLCR)  <-  CSCT) 
recaivarlD  ■  UaerXO 

e.  access  secure:  to  obtain  mail  from  buffers. 

CSCM)  <•  CSLCprocasa) 
aceaaa  rigbt 

f.  store  secure:  to  store  mail  into  a  buffer  or  to  display  mail  on  terminal. 

CSLCprocass)  <■  CSCobjact) 

g.  forward  secure 

CSLCIF  sub  il)  •  CSLC$A  sub  jl) 
sncrypt ion/dscrypt ion 

share  l,j  are  nodes  that  are  connected. 

h.  Server  is  secure  if  and  only  if 

1.  login  secure 

2.  reclassify  secure 

3.  send  secure 

4.  retrieve  secure 

5.  access  secure 

6.  store  secure 

7.  forward  secure 

9.1.5  Discussion 

Mail  Delivery  The  model  guarantees  that  users  may  only  receive  mail  that  are  sent  to  them. 
This  is  done  by  the  switching  process  and  the  retrieve  procen.  Furthermore,  a  sender  does  not 
have  to  identify  the  security  clearance  of  a  receiver  when  he  sends  a  maO  to  the  receiver.  If  the 
sender  classifies  the  mail  correctly,  the  model  will  prevent  receivers  with  lower  security  clearance 
from  reading  the  mail.  The  model  also  protects  users  from  exposing  their  security  clearances  from 
users  with  lower  clearances. 

The  model  also  guarantees  mail  delivery  if  (1)  there  is  a  path  between  the  sender's  node  and 
the  receiver’s  node;  (2)  the  routing  information  is  available  at  each  node;  and  (3)  the  number  of 
undelivered  messages  is  less  than  the  number  of  messages  in  the  switch  buffer  and  the  output  buffer. 
The  integrity  and  privacy  of  mail  is  enforced  by  the  link  to  link  encryption  and  decryption, 
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e.  Each  network  user  has  a  unique  U)  and  a  password. 

f.  All  devices  in  the  network  have  comparable  security  classes. 

g.  Each  server  knows  how  to  route  mail  to  proper  destination. 

h.  Reliable  information  transmission  across  the  network  is  available. 

i.  A  reliable  user  authentication  mechanism  and  a  good  encryption/decryption  mechanism  are 
available. 


Security  Assertions  Mail  server  security  assertions: 

Al.  The  classification  of  created  mail  must  be  equal  to  the  current  security  level  of  sender. 

A2.  A  sender  may  send  m^  to  another  user  with  security  clearance  equal  to  or  less  than  the 
security  clearance  of  the  sender. 

A3.  Server  process  may  read  mail  with  classification  less  than  or  equal  to  the  current  security 
clearance  of  the  process. 

A4.  The  classification  of  retrieved  mail  is  less  than  or  equal  to  the  current  security  level  of  the 
receiver. 

A5.  Information  removed  from  an  object  inherits  the  object’s  classification. 

Network  security  assertions: 

A6.  A  user  can  use  a  terminal  only  when  his  security  clearance  is  higher  than  or  equal  to  the 
classification  of  that  terminal. 

A7.  A  terminal  may  connect  to  a  server  if  clearance  of  the  connected  server  is  less  than  or 
equal  to  the  clearance  of  the  terminal. 

A8.  A  server  may  forward  mail  to  server  of  a  nmghboring  node  if  their  current  security  levels 
are  the  same. 

A9.  Any  information  transmitted  over  the  network  must  be  labeled  with  its  classification  and 
is  in  an  encrypted  format. 

AlO.  Noise  is  inserted  randomly  in  the  network  by  the  server. 


Notations 

Let  U 
T 
S 
R 

A 

F 

SV 

SB 

LB 

FB 

M 


denote  user, 
denote  teminal 
denote  server’s 
denote  server’s 
denote  server’s 
denote  server’s 
denote  server’s 
denote  server’s 
denote  server’s 
denote  server’s 
denote  smll. 


send  process, 
retrieve  process 
accept  process, 
forvard  process, 
svltch  process, 
switch  buffer, 
local  buffer, 
forward  buffer. 


CS  denote  object’s  classification, 

CL  denote  subject’s  security  clearance  level, 
CSL  denote  subject’s  current  security  level. 


Security  Requirements  The  security  requirements  of  the  proposed  mail  system  consists  of  the 
following  rules.  Figure  1  above  contains  the  architecture  and  the  security  requirements  of  a  mail 
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ftnd  by  the  good  encryption/decryption  mechanism.  Hence,  an  eavesdropper  may  not  be  able  to 
comprehend  content  of  an  intercepted  mail. 

Covert  Channel  An  eavesdropper  may  rely  on  convert  channel  to  deduce  useful  information.  For 
example,  by  observing  the  activity  of  the  network  link,  an  eavesdropper  may  be  able  to  identify  the 
identity  of  the  sender;  by  inferendng  the  buffer  overflow  message,  a  user  may  be  able  to  determine 
the  traffic  of  a  given  class  of  mail  in  the  network;  by  tending  mail  with  different  classiflcations  to 
a  particular  user,  a  sender  may  be  able  to  identify  the  security  clearance  of  the  receiver. 

Since  covert  channel  can  not  be  eliminated  completely,  the  proposed  model  attempts  to  reduce 
the  bandwidth  of  leaked  information.  The  bandwidth  reduction  is  accomplished  by  the  following 
four  mechanisms: 

First,  all  data  sent  across  network  link  are  encrypted  at  the  sending  node  and  are  decrypted 
at  the  receiving  node.  By  doing  so,  we  can  reduce  the  comprehensibility  of  an  intercepted  mail. 

Second,  nmse  is  inserted  randomly  into  the  network  by  mail  servers.  The  purpose  of  intro¬ 
ducing  noise  into  the  network  is  to  confuse  an  eavesdropper  from  distinguishing  real  mail  from  all 
intercepted  data.  In  reality,  the  noise  may  contain  useful  information  such  as  netw.''rk  topology. 

Third,  the  model  prevents  users  with  lower  security  clearance  from  identifying  users  with  higher 
clearance.  This  is  corresponding  with  real  life  situation  in  which  high  security  clearance  personnel 
will  often  be  aware  the  identity  of  personnel  with  lower  clearance  but  not  vice  versa. 

Fourth,  all  mail  is  stored  in  a  multilevel  buffer.  Hence,  if  the  buffer  is  full,  a  sender  can  not 
infer  the  traffic  of  a  given  class  of  mail. 

9.1.6  Coacluaions 

In  this  section  we  have  examined  a  secure  network  mail  system  model  in  which  the  correct  mail 
delivery  property  is  enforced  by  the  access  control  mechanism,  in  which  the  authorued  information 
dissemination  property  is  enforced  by  the  security  clearance  mechanism,  and  in  which  the  integrity 
and  privacy  property  is  enforced  by  the  encryption  and  decryption  mechanism.  Similar  to  the 
Owicki  network  mail  system  model,  the  guaranteed  delivery  property  may  be  asserted  if  the  number 
of  undelivered  mail  is  less  than  the  number  of  messages  in  the  switch  buffer  and  in  the  local  buffer 
and  if  the  routing  is  possible. 

Even  though  covert  channels  cannot  be  eliminated  entirely,  the  model  does  reduce  the  band¬ 
width  covert  channel.  The  reduction  is  made  possible  by  randomly  inserting  noise  in  the  network, 
by  encrypting  mail-in>transit,  and  by  placing  mail  with  different  clasufications  in  the  same  buffer. 

The  model  assumes  that  the  server  can  be  trusted  and  that  mail  delivery  can  be  guaranteed 
by  the  routing  mechanism. 
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Figure  2:  SDOS  Object  Hierarchy 

9.2  Initial  Results  on  Specifying  SDOS  ! 

We  have  begun  to  apply  the  OBJ-based  specihcation  methodology  described  in  Section  4.2  to  a 
number  of  larger  examples.  One  of  these  examples  is  a  preliminary  OBJC  spedlication  of  the  . 

Secure  Distributed  Operating  System  (SDOS)  described  in  [VCH88,  TCVW*88].  j 

Given  the  distributed  structure  of  SDOS,  OBJC  is  well-suited  to  express  its  overall  specifica¬ 
tion.  To  date,  we  have  only  a  major  outline  of  SDOS  specified  in  OBJC,  but  what  we  do  have  is  i 

quite  promising  as  an  indication  of  the  practicality  of  OBJC  for  distributed  system  specification.  j 

Figure  2  is  a  high-level  diagram  of  the  OBJC  objects  that  comprise  the  specification.  This 
OBJC  object  hierarchy  accurately  reflects  the  high-level  organisation  of  SDOS  as  described  in 
(VCH88].  The  details  of  the  OBJC  SDOS  objects  are  given  in  subsection  9.2.1.  Subsection  9.2.2 
»  discussion  of  how  the  OBJC  specification  of  SDOS  can  be  constructed  to  permit  the 
verifcation  of  security  properties  using  a  state-machine  approach,  as  suggested  by  the  SDOS  authors. 
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0.2.1  High-Level  Outline  of  an  OBJC  Specification  of  SDOS 

Selected  objects  from  the  SDOS  specification  outline  are  defined  below  in  OBJC.  S,efer  to  Figure  2 

for  the  hierarchical  organization  of  the  objects.  The  syntax  and  semantics  of  OBJC  were  discussed 

in  Section  4.2  of  the  report. 

object  INTERNET  is 
sort  Internet  . 
protecting  ETHERNET  . 
op  internet  :  Ethernet  Ethernet 
->  Internet  . 

endo 

object  ETHERNET  is 
sort  Ethernet  . 
protecting  SDOS  . 
op  ethemet  :  Sdos  Sdos  Sdos 
->  Ethemet  . 

endo 

object  SDOS  is 
son  Sdos  . 

protecting  SVCTCB  4  NANAGER  4  CLIENT  . 
define  Manager-List  is  LISTCManagerj  . 
define  Client-List  is  LISTCClient]  . 
op  sdos  :  Sviteh  Manager-List  Client-List 
->  Sdos  . 

endo 

object  SWITCH  is 
sort  Switch  . 

protecting  MESSAGE-HANDLER  . 
define  Message-Haadler-List  is 
LISTCMessage-Bandler]  . 
op  switch  :  Message-Handler-List 
->  Switch  . 

endo 

object  NAME-CLIENT  is 
sort  Naae-Client  . 
protecting  MESSAGE [INT]  . 
op  new-naae-client  :  ->  Naae-Client  . 
op  naae-client  :  Message  ->  Naae-Client  . 
war  N  :  MessageNua  . 
eq  new-naae-elient  ■ 

naae-clientfsendC’NaaeLocal.O))  . 
eq  naae-client (sent C'NaaeLocal.N.O})  • 
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naB*-cli«zit(vait(N,0))  . 


•ndo 

Ob j act  MANE-NANAGER  is 
sort  NaBS-K«nagar  . 
protacting  MESSAGE [INT]  . 
op  naa-naBa-msnagar  :  Int 
->  Kasa-Managar  . 
op  naaa-Banagar  :  Massaga  Int 
->  Naaa-Managar  . 

▼ar  H  :  MassagaMun  . 

Tar  M  :  Int  . 
aq  nav-'naaa-aanagar(N)  ■ 

naaa-aanagar(raealTa( ’Haaa.O) ,N)  . 
aq  naaa'BanagarCracaiTadC’Haaa.V.O) .H)  ■ 
naBa-Banagar(raply(N.M) ,N)  . 
aq  nama-BanagarCraplladCN.M) .M}  ■ 

naBa-Banagar(racaiTa('NaBa,0) ,M  *  1)  . 

ando 

Given  the  object  definitions  above,  the  SDOS  system  behavior  will  be  modeled  by  OBJC  input 
and  output  terms  of  the  form  shown  below.  The  example  top-level  input  term  shows  an  internet 
with  two  ethemet  clients,  each  of  which  have  in  tom  three  sdos  processes,  with  a  single  active 
client  and  manager.  The  sample  switch,  client,  and  manager  terms  dq>ict  farther  details  of  the 
initial  input  state  of  the  system.  Here  a  simple  client-bound  message  with  content  *1234”  is  shown 
residing  in  the  application  manager. 

Top-Level  Input  Term: 

intamat  ( 
atbamatf 

sdos  (swttche ,nil ,  client) , 
sdos (sTitch (nil) .nil, nil) . 
sdos (switch (nil) .nil, nil)) . 
athamat( 

9doti$witchf^,manager,nil) , 
sdos (switch (nil) .nil .nil) . 
sdos (switch (nil) .nil .nil) ) )  . 

Switch,  Client,  and  Manager  Input  Terms: 
switch ( 

Bassaga-handlar ( 

naw-naae-cliant'-aassaga-handlar)  ) 
client ( 

application-client ( 
nsw-naBs-cliant) ) 
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■vitchC 

••••kga-handlar ( 

n««*n*m«>Banag«r-B«Bsag«-huidl«r) ) 

B«n«g«r( 

appllcation>Ban«g«r( 
n«w-naB«>B«nag«r ( 1234) ) ) . 

Shown  below  are  the  resulting  output  terms  when  the  *1234”  message  has  been  transmitted, 
via  the  switches,  to  the  application-client.  The  next  message,  ”1235”  is  now  shown  as  pending. 

Switch,  Client,  and  Manager  Input  Terms: 

•witch ( 

aesaage-handler ( 

neahCreceivlngC’laaeLocal.O) ,0))} 
client ( 

applicatioB'-client  ( 

aaae*client(waited((101)  .llzNat,1234)))) 

•witch ( 

aeccagwhandlerC 

naidi  (receiving  C'laaeGlobal.O)  ,0))) 

BanagerC 

appl icat ion-Banager ( 
naBS'Banager (recaiving( ' VsBe ,0) , 1235) ) ) 

8.2.2  Verifying  Security  Propertiew  of  the  OBJC  Specification  of  SDOS 

The  primary  co-developers  of  OBJ3,  J.  Goguen  and  J.  Mesegner,  have  also  done  foundational  work 
on  the  verification  of  security  (GM82,  GM84].  In  [GM82,  GM84]  they  describe  the  Gognen-Meseguer 
methodology  for  security  verification,  and  indicate  how  specifications  written  in  a  language  such  as 
OBJ3  fit  into  their  methodology. 

This  subsection  of  the  report  investigates  the  connection  between  OBJC  specifications  and  the 
(3ogucn-Mesegner  security  vacation  methodology.  The  general  propostion  put  forth  here  is  that 
if  an  OBJC  specification  structured  as  a  secure  state  machine,  then  its  security  can  be  verified 
using  the  (Soguen-Meseguer  methodology.  Details  are  presented  of  how  to  so  structure  the  OBJC 
specification  of  SDOS. 

Overview  Since  an  OBJC  spedfication  is  (intuitivriy)  a  lattice  of  objects,  we  begin  by  naming 
and  informally  describing  the  important  objects  in  the  lattice.  Strictly  spealoBg,  the  SDOS  object 
should  be  at  the  top  of  the  lattice;  but  in  order  to  permit  testing  and  demonstration,  other  objects 
are  placed  above  and  orthogonal  to  it. 

SDOS  is  a  distributed  operating  system:  it  runs  on  a  network  of  host  machines.  This  does 
not  mean  that  each  host  is  running  a  part  of  SDOS;  it  means  that  each  host  is  running  a  copy  of 
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SDOS  &nd  that  a  job  started  at  one  host  can  mn  (partially  or  whoUy)  on  another  host.  Job  sharing 
requires  interSDOS  communication,  which  is  something  more  than  inter  host  communication. 

Goguen-Meseguer  applies  only  to  nondistributed  concurrent  systems.  This  is  because  a 
Goguen-Meseguer  state  machine  can  only  model  a  single  multiuser  host  —  not  multiple  communi¬ 
cating  hosts.  In  order  to  overcome  this  restriction,  Goguen-Meseguer  is  not  applied  to  the  top  of 
the  lattice,  thereby  verifying  the  INTERNET  object;  it  is  applied  to  the  sublattice  at  and  below  the 
SDOS  object,  thereby  accomplishing  the  original  goal.  Plainly  put:  the  interhost  communication 
provided  the  communication  primitives  of  OBJC  is  assumed  correct  and  secure. 

User  Interface  A  Goguen-Meseguer  state  machine  executes  user  commands.  For  the  SDOS  state 
machine,  user  commands  are  somewhat  subtle.  One  problem  is  that  the  command  set  of  a  state 
machine  is  constant,  but  an  SDOS  user  can  write  new  programs  that  appear  to  be,  or  even  replace, 
those  originally  provided.  Another  problem  is  that  a  state  machine  (even  a  Turing  machine)  cannot 
obtain  additional  input  during  computation.  With  these  problems  in  mind,  consider  a  user  to  be  a 
person  at  a  terminal  and  the  command  set  to  consist  of  the  single  command 
run  <usor-naBe>  <progran>nama>  <input-data> 

What  are  the  advantages  of  this  perspective?  Does  it  cause  problems?  This  is  considered  below. 

Logging  on  and  off  is  no  longer  a  special  procedure.  A  terminal  is  always  connected  to  SDOS. 
A  session  begins  with 

run  <u8er-naBe>  login  <pa88uord> 
and  ends  with 

run  <u8er-naaie>  logout 

and  all  user  commands  between  logout  and  login  (as  well  as  a  user’s  second  login)  are  SDOS 
no-ops.  Notice  that  multiple  users  can  be  logged  onto  a  terminal  simultaneously.  More  practically, 
a  terminal  can  supply  the  first  two  fields  of  every  command. 

There  is  only  one  command  and  its  semantics  are  constant. 

During  execution,  the  state  machine  does  not  interact  with  the  user  to  obtain  input  data. 
The  data  either  comes  directly  from  the  command  line  or  from  within  SDOS  as  addressed  by  the 
command  line.  Such  an  address  denotes  data  that  is  either  in  memory  or  the  file  system. 

The  file  system  is  internal  to  SDOS.  More  specifically,  every  user  has  their  own  file  system. 
File  ownership  is  determined  by  a  file’s  location.  Together,  the  file  systems  satisfy  a  security  policy 
at  least  as  strong  as  that  satisfied  by  SDOS. 

Since  a  state  machine  has  only  a  single-level  command  set,  there  are  no  “system  calls”  or  “ma¬ 
chine  instructions”  that  can  be  called  from  a  program.  Therefore,  a  user-written  program  is  simply 
a  textual  sequence  of  run  commands.  This  has  several  ramifications.  A  user  who  writes  programs 
has  no  new  method  of  violating  the  security  policy.  Running  a  data  file  is  no  worse  than  typing 
the  data  at  the  keyboard.  A  suitable  collection  of  provided  programs  renders  other  programming 
languages  strictly  unnecessary.  More  practicaUy,  a  compiler  whose  output  is  a  sequence  of  nm 
commands  can  be  provided  or  even  written  with  run  commands.  An  alternate  approach  is  to  have 
some  programs  accessible  only  from  programs  and  not  from  the  conunand  line;  but  since  all  run 
commands,  hence  all  programs,  must  satisfy  the  security  policy,  this  is  just  an  optimization. 

A  program  that  is  mn  by  a  user  other  than  the  owner  can  do  what  the  user,  the  owner,  or 
some  combination  can  do.  This  capability  is  contndled  by  SDOS  and  any  user  that  can  update  the 
program.  Since  each  command  in  a  program  has  a  <u8er-nane>  field,  that  is  the  granularity. 
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Import  Lattice  The  objects  at  the  upper  nodes  of  the  import  lattice  are  described  here.  The 

objects  they  import  are  also  listed. 

INTERNET  This  object  provides  context  for  communication  between  hosts. 

•  HOST 

HOST  This  object  encapsulates  the  components  of  a  host  computer:  its  users  and  the  operating 
system. 

•  USER 

•  SDOS 

USER  This  object  models  a  person  at  a  terminal  connected  to  a  host  running  SDOS.  Commands 
and  results  are  transferred  between  user  and  host  as  OBJC  messages.  A  user  behaves  as  a 
client  that  runs  programs  by  twalting  run  requests  of  an  SDOS  server. 

•  REQUEST-RESULT 

SDOS  This  object  encapulates  the  major  components  of  SDOS.  An  SDOS  behaves  as  a  server. 
It  accepts,  services,  and  returns  the  results  of  run  requests  from  users  through  the  interface 
subsystem.  Communication  between  user  and  host  is  accomplished  with  OBJC  messages. 
The  other  subsystems  operate  as  internal  servers;  they  are  not  directly  accessible  to  users. 

•  INTERFACE-SS 

e  SECURITY-SS 

•  RUN-SS 

•  FUE-SS 

•  VAR-SS 

INTERFACE-SS  This  object  is  the  user  interface  for  SDOS.  It  accepts  run  requests  from  users, 
dispatches  internal  requests  to  service  them,  maintains  information  about  active  requests, 
and  returns  the  result  of  serviced  requests  to  the  users.  Before  servicing  a  user’s  request,  the 
login  status  and  security  level  of  the  user  is  requested  from  the  security  subsystem.  Requests 
are: 


op  run  :  Uaerlane  Prograalaae  ZnputOata  «>  . 

SECUBITY-SS  This  object  security  information  about  users  and  services  requests 

concerning  it.  This  information  is  initialised  during  startup.  Requests  are: 


op  login  :  Ueerlaae  •>  . 
op  logout  :  Userlane  •>  . 
op  get-login  :  Userlaae  ->  . 
op  get-level  :  Userlaae  ->  . 

RUN-SS  This  object  runs  programs.  A  program  is  either  a  builtin  program  or  a  file  of -run 
commands.  The  search-path  variable  resolves  ambiguous  program  names.  Requests  are: 
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op  run  :  UsorNamo  S«cL«v  Progra&Naa*  InputData  ->  . 

FILE-SS  This  object  maintains  user  files.  Each  user  has  a  separate  set  of  ^es.  Subject  to 
security,  a  user  can  access  another  user’s  files  by  qualifying  a  file  reference  by  the  owner’s 
name.  Requests  are: 

op  gat-fila  :  UsarNaaa  SacLav  FilaNana  FilaPos  ->  . 
op  put-fila  :  UsarNama  SacLav  FilaNana  FilaPos  FilaData  ->  . 
op  ram-fila  :  UsarNama  SacLav  FilaNana  ->  . 

VAR>SS  This  object  maintains  user  variables.  Each  user  has  a  separate  set  of  variables.  Subject 
to  security,  a  user  can  access  another  user’s  variables  by  qualifying  a  variable  reference  by  the 
owner’s  name.  Requests  are: 

op  gat-var  :  UsarNana  SacLav  VarNana  •>  . 
op  put-var  :  UsarNana  SacLav  VarNana  VarData  ->  . 
op  ran-var  :  UsarNana  SacLav  VarNana  ->  . 
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9.3  A  Security  Kernel  for  Distributed  Systems 

One  of  the  longer-term  retesrch  efforts  we  would  like  to  undertake  is  the  complete  formal  spedhca- 
tion  of  a  security  kernel  for  a  distributed  computer  system.  This  keriMl  will  be  the  Software  portion 
of  a  trusted  computing  base  satisfying  the  criteria  for  an  A1  level  secure  system  as  defined  by  the 
Department  of  Defense. 

In  this  section  of  the  report  we  present  our  ideas  on  this  kernel.  We  begin  with  a  survey  of 
related  work  followed  by  the  discussion  of  our  proposed  kernel. 

The  aim  of  the  the  kernel  is  to  provide  a  set  of  primitive  services  that  manage  resource  al¬ 
location,  communication,  and  process  manipulation  while  ensuring  the  security  properties  of  the 
system.  Using  the  kernel,  the  system  developer  will  be  able  to  create  software  systems  that  are 
guaranteed  to  satisfy  formally  spedfed  security  polides. 

9.S.1  Overview  of  Previous  Research 

Since  distributed  operating  systems  and  computer  system  security  are  such  important  subjects, 
there  has  been  a  lot  of  research  in  these  areas.  This  subsection  surveys  several  of  these  systems  in 
an  attempt  to  give  an  overall  view  of  the  areas  that  have  currently  been  explored. 

Distributed  Operating  System  Kernels  One  type  of  computer  operating  system  is  the  dis¬ 
tributed  operating  system.  The  following  two  systems  are  examples  of  Distributed  Operating 
System  Kernels.  These  systems  help  enumerate  the  particular  issues  being  evaluated  using  this 
type  of  system: 

•  Security.  In  these  systems  security  is  considered  a  side  issue.  It  appears  that  the  other 
issues  take  precedence  and  once  they  have  been  developed  into  a  standard  methodology  then 
security  will  become  more  central.  Until  then  data  integrity  and  minimal  access  controls  are 
all  the  security  seen  in  these  systems. 

•  Integrity.  In  a  distributed  environment,  where  data  caching  is  implemented  for  performance 
improvement  and  resource  sharing  is  permitted,  we  need  to  worry  about  the  integrity  of  the 
data.  These  systems  try  to  develop  methods  for  insuring  that  the  data  remains  consistent  yet 
performance  is  not  hindered.  The  Alpha  system  even  goes  so  far  as  to  limit  the  loss  of  data 
when  a  portion  of  the  system  goes  down. 

•  Resource  Management.  In  a  distribute  system  there  is  a  wide  variety  of  resources  that  must 
be  managed  fairly  and  effidently.  These  systems  try  to  develop  the  best  methods  for  handling 
the  resources. 

•  Support:  These  systems  are  very  different  in  the  applications  they  support.  The  Alpha  kernel 
supports  real-time  applicatioxu  developed  for  it  spedffcally,  where  the  V  kernel  provides  a  set 
of  language  tools  to  aDow  a  wide  variety  of  applications  to  run  on  it. 

•  Performance.  Performance  is  one  of  the  key  issues  in  this  area.  The  ability  of  the  kernel 
to  respond  quickly  to  the  dynamic  nature  of  the  distributed  system,  servicing  requests  and 
scheduling  processes  in  a  fair  and  efficient  manner  is  addressed  in  both  of  these  systems. 
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Alpha  Kernel  The  Alpha  Kernel  (Nor87]  is  a  decentralized^  operating  system  kernel  for  a 
real'time  command  and  control  system.  It  is  the  initial  phase  of  the  implementation  of  the  Archons 
projects  at  Concurrent  Computing  Corporation  led  by  E.  Douglas  Jensen. 

The  kernel  executes  as  a  set  of  identical  processes  running  on  a  system  of  connected  homoge¬ 
neous  hosts.  The  hosts  are  meant  to  number  from  10  to  100  and  be  separated  by  no  more  that 
on  the  order  of  1000  meters.  These  processes  cooperate  to  present  to  the  client  processes  the 
appearance  of  a  single  computer,  completely  hiding  the  decentralized  nature  of  the  system. 

Currently,  to  keep  the  project  manageable,  security  has  not  be  addressed  in  the  Alpha  kernel. 
It  is  a  concept  that  will  soon  be  looked  at. 

This  kernel  is  meant  to  support  a  system  that  provides  services  for  a  single  real-time  command 
and  control  application.  There  is  no  concept  of  multiple  users  or  a  diversity  of  processes.  The  single 
application  executes  as  a  set  of  threads  running  through  several  objects  (possible  concurrently). 
These  threads  have  real-time  constraints  on  their  performance  that  the  kernel  must  be  able  to 
support. 

V  Distributed  System  The  V  distributed  system  is  part  of  an  ongoing  research  project  to 
study  issues  in  distributed  systems.  The  project  is  lead  by  D.&.  Cheriton  at  Stanford  University  and 
has  produced  numerous  thesis  topics  and  results  over  the  last  several  years.  It  provides  a  “hands- 
on”  capability  for  testing  new  methodologies  and  experimenting  with  different  system  parameters 
[Che88]. 

This  system  is  based  on  a  collection  of  workstations  connected  by  a  high-performance  network. 
The  primary  configuration  is  that  of  diskless  workstations  connected  to  a  set  of  file  servers  by  the 
network  [CZ83].  This  configuration  allows  a  process  to  be  scheduled  on  different  hosts  during  its 
lifetime.  Since  the  process  gets  swapped  out  to  a  shared  file  server  when  not  being  executed,  it  can 
easily  be  swapped  in  on  another  machine  thus  “migrating”  the  process  among  the  machines.  The 
scheduler  that  handles  this  migration  is  designed  to  prioritorize  processes  and  then  schedule  the 
top  n  processes  on  the  n  machines  in  the  system. 

Although  mentioned  briefly  in  the  literature,  there  appears  to  be  no  overt  attempt  to  ensure 
security  in  this  system.  The  main  emphasis  seems  to  be  placed  on  performance  measures  and 
efficiency.  Since  the  system  is  part  of  a  continuous  project,  and  the  specifications  of  the  system 
change  with  time,  it  seems  that  it  would  be  very  difficult  to  ensure  anything  more  than  some 
rudimentary  security  properties. 

The  system  is  designed  to  provide  a  high  level  of  performance  to  a  collection  of  applications 
developed  using  kernel  specific  run-time  modules  for  popular  programming  languages  (ie.,  Pas¬ 
cal,  C).  The  system  also  supports  co-location  of  servers  with  the  hardware  they  serve  to  reduce 
communication  slow  down  and  thus  permit  the  use  of  real-time  control  applications. 

This  system  emphasizes  issues  that  are  also  important  to  the  kernel  proposed  in  our  research. 
The  major  difference  is  that  the  V  system  does  not  have  a  formal  sense  of  security  that  is  crucial 
to  this  our  research. 

Security  Kernels  Another  form  of  secure  operating  system  is  the  security  kernel.  This  system 
is  based  on  g«i«g  a  minimal tn  set  of  secure  operations  in  the  kernel.  These  operations  are  then  used 
to  build  the  overall  system. 

*Tke  sstkof  defiaes  tke  iTatcm  m  dcceatnliicd  to  avoid  saj  ambiinity  with  the  popolaz  tena  distributed.  The 
syetem  is  deceatralised  smce  it  executes  m  coopentiag  processes  oa  physically  sepsrsted  hosts 
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The  following  systems  axe  all  examples  of  Security  Kernels.  These  systems  help  enumerate  the 
issues  being  explored  in  this  type  of  system; 

•  Security:  Each  of  these  systems  tries  to  maintain  a  certain  security  policy.  This  is  the  reason 
for  the  existence  of  the  kernel  and  thus  is  the  most  important  issue  here.  These  kernels 
try  to  separate  “IVusted”  and  “Untrusted”  processes.  The  trusted  processes  are  verified  to 
maintain  the  security  of  the  system  and  thus  avoid  the  internal  checks  performed  by  the  kernel 
on  operations  of  untrusted  processes. 

•  Integrity:  Data  integrity  is  a  concern  in  these  system.  They  use  different  techniques  to 
maintain  that  changes  to  system  data  is  a  result  of  verified  or  trusted  operations. 

•  Besource  Management:  These  systems  each  take  different  approaches  to  management  of  the 
resources  of  the  system.  The  differences  occur  in  how  the  resources  are  allocated,  how  the 
access  to  the  resources  is  managed  and  exactly  what  the  resources  are. 

•  Support:  Another  issue  being  looked  at  in  these  systems  is  support.  In  the  systems  below 
three  of  them  are  designed  to  support  a  UNIX-like  interface  executing  on  top  of  the  kernel, 
the  other  system  is  meant  to  be  a  secure  execution  environment  for  ADA. 

•  Performance:  Again  performance  is  considered  a  major  issue  where  the  implementation  of 
the  kernel  tries  to  keep  the  system  efBcient. 

KSOS  In  the  late  1970’s  there  was  a  project  at  Ford  Aerospace  to  develop  a  provably  secure 
operating  system  [MD79].  This  system,  Kemelized  Secure  Operating  System  (KSOS),  is  intended 
to  be  a  fully  functional  multilevel  secure  operatu^;  system  with  a  Unix-like  interface  for  larger 
minicomputers. 

The  system  is  based  on  the  security  kernel  concept.  The  kernel  provides  the  basic  operating 
system  functionality,  and  is  enhanced  by  the  inclusion  of  trusted  and  untrusted  system  support 
processes.  These  processes  execute  in  three  different  modes. 

In  the  kernel  mode  is  the  security  kernel.  This  kernel  must  be  a  fully  verified  multilevel 
operating  system  kernel.  It  has  complete  access  to  the  whole  system  and  provides  the  interface 
between  the  system  and  the  client  processes.  Each  invocation  of  an  operation  supported  by  the 
kernel  will  be  executed  only  if  the  calling  process  has  the  correct  authorization  to  execute  that 
operation.  In  other  words,  the  invoked  operation  has  to  comply  with  the  implemented  security 
policy. 

In  the  supervisor  mode  there  is  the  Unix  emulator  (an  untrusted  process)  that  translates  Unix- 
like  system  calls  into  kernel  calls  on  behalf  of  the  original  invoking  process.  Also  at  this  level  is 
the  trusted  non-kernel  security  related  software  (NKSR).  These  processes  are  completely  verified 
routines  that  perform  neceuary  security  related  operations  that  possibly  violate  the  strict  definition 
of  the  security  policy.^ 

This  system  provides  a  basis  for  execution  of  Unix  processes  in  a  secure  environment  by 
logically  separating  processes  of  different  security  classifications  onto  separate  virtual  machines.  It 
also  permits  the  development  of  different  execution  environments  by  allowing  server  processes  that 
execute  in  the  supervisor  mode  to  emulate  those  environments. 

*KSOS  impleaeata  s  teem  Me  terrei  »t  ibit  levd.  Tke  eemr  tUnt  Met  st  aeveral  differest  Mcarity  level*  to 
it  moat  be  ckarcd  for  the  higbcet  of  tb*M  levels.  It  ku  to  pczadt  lower  levd  rabjeets  to  lesd  tkcix  files  ud  tkn* 
vioUtc*  tbe  “-Property. 


Although  this  system  supports  data  security  and  separation  using  the  operating  system  ker¬ 
nel  model,  it  does  not  support  any  concept  of  distributed  programming,  but  rather  connects  the 
machines  through  standard  network  protocols. 

LOCK  (wan  SAT  —  was  PSOS)  The  LOgical  Coprocessing  Kernel  (LOCK)  is  a  current 
research  effort  by  Secure  Computing  Technology  Corporation  to  develop  a  hardware-oriented  so¬ 
lution  to  the  problem  of  multilevel  secure  computer  system  development.  The  project  is  based  on 
the  SRI  specification  of  the  Provably  Secure  Operating  System  (PSOS)  [NBF*80].  The  hardware 
portion  of  the  Trusted  Computing  Base  specified  by  a  Ford  Aerospace  attempt  to  implement  PSOS 
[FOR80],  was  picked  up  by  Honeywell  in  1982  as  the  Secure  Ada  Target  project  (SAT).  LOCK 
is  the  third  phase  of  the  SAT  project  to  generate  a  "detailed  design  specification  and  a  secure 
microcomputer  prototype  by  1990”  [SK86]. 

The  LOCK  system  is  designed  to  attach  a  generic  coprocessing  unit  (SIDEABld)  onto  a  mi¬ 
crocomputer  bus.  The  unit  will  act  as  reference  monitor  for  the  CPU  and  its  resources.  It  consists 
of  one  to  four  microprocessors  with  their  own  volatile  and  non-volatile  memory  and  a  separate  long 
term  storage  device. 

This  system  will  maintain  the  non-interference  model  of  Goguen  and  Meseguer  [GM84]  with 
respect  to  the  TCSEC  A1  level  specifications.  This  is  done  through  the  management  of  the  reference 
monitor  and  additional  two-level  encryption  of  secure  data.  This  encryption  enables  the  system  to 
use  standard  hardware  for  communication  lines  and  long  term  storage  by  ensuring  that  the  data 
going  on  these  devices  is  unusable  to  any  unauthorixed  process  or  person. 

The  system  is  designed  with  a  generic  interface  that  will  attach  to  a  small  machine-specific 
device  called  the  host  interface  connector.  This  device  and  its  functionality  will  have  to  be  proven 
for  each  machine.  But,  since  it  is  a  small  interface  not  much  difficulty  is  seen  here. 

The  initial  prototype  of  the  LOCK  system  will  retrofit  Kernel  Extensions  of  the  system  into  the 
security  relevant  portions  of  a  UNIX  operating  system.  The  idea  is  that  with  this  small  adjustment 
(and  a  few  others  not  yet  determined  to  the  operating  system,  the  addition  of  the  SIDEARM  will 
create  a  secure  system  with  little  performance  degradation  (performance  should  be  80%  of  the 
original  system). 

This  system  is  specifically  designed  for  a  single  host  with  little  mention  of  connecting  it  to  a 
network,  and  no  mention  of  a  distributed  system.  ^  Placing  a  lot  of  the  security  relevant  functions 
in  hardware  is  a  good  way  to  improve  performance  and  ensure  reliability  and  integrity.  With  recent 
developments  in  microprocessors  that  have  built  in  resource  management  units,  such  as  the  Intel 
80386  [INT86],  all  this  work  may  be  overkill  and  actually  perform  less  efficiently  than  a  software 
based  system  that  uses  the  microprocessors  full  potential. 

Secure  Xenix  The  Secure  Xenix  system  is  an  "experimental  system  designed  to  run  on 
IBM  PC/AT  workstatioiu”  [GCC*87].  This  project  is  headed  by  V.D.  Gligor  at  t.'-e  University  of 
Maryland. 

The  system  is  deigned  to  meet  the  spedfications  of  B2-A1  level  as  defined  by  TCSEC.  To 
meet  this  classification  level  they  add  an  Access  Control  List  mechanism  to  the  standard  UNIX 
interface.  This  mechanism  allows  the  system  and  users  to  implement  mandatory  and  discretionary 
access  controls  and  maintains  the  required  audit  functionality. 

*CoBbiBiag  this  •ystem  with  the  THETA  system  mcatioaed  later  may  be  aa  effective  way  to  develop  a  seenre 
distnbsted  system  if  the  iatcxlace  between  the  two  is  similar  caonsh. 
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la  addition  to  the  added  access  control  the  system  includes  a  Secure  Access  Key  (SAK)  mech¬ 
anism  where,  by  a  few  special  keystrokes,  the  user  ensures  an  authenticated  communication  path 
directly  connected  to  the  kernel.  This  will  permit  the  user  to  perform  operations  -that  may  violate  a 
precise  interpretation  of  the  security  policy  but  not  the  spirit  of  it,  and  also  to  change  their  current 
classification  level. 

To  maintain  the  security  policy  in  the  standardized  tTNDC  file  system,  they  create  virtual 
directories  for  each  security  classification.  Thus  when  a  UNIX  process  writes  to,  or  is  swapped  to 
the  ‘Hmp”  directory,  the  data  is  considered  secure. 

The  system  also  separates  information  by  creating  a  separate  process  for  each  command  of 
administrative  users.  These  processes  are  further  divided  into  trusted  processes  that  do  not  require 
superuser  privileges  and  those  that  do. 

Overall,  this  system  seems  like  a  good  concept,  but  they  are  tr]ring  to  retrofit  security  into  an 
existing  system  design.  Segardleu  of  the  system,  the  designers  inevitably  have  to  "hack”  something 
to  make  up  for  an  assumption  the  original  system  made^.  Such  unconventional  modifications  will 
make  the  design  and  proof  of  the  system  much  more  difficult. 

UCLA  Security  Kernel  The  UCLA  Data  Secure  Unix  operating  system  was  developed 
in  the  late  70 's  as  a  demonstration  that  general  purpose  functionality  and  verifiable  data  security 
are  attainable  [PKK*79].  The  UCLA  Unix  architecture  is  based  on  DEC  PDP>ll/45s  and  PDP- 
ll/70s.  The  kernel  executes  as  a  single  process  in  the  hardware  kernel  mode  on  the  host  machine 
managing  all  client  requests  for  machine  resources. 

Sitting  above  the  kernel  and  executing  in  the  hardware  supervisor  mode  are  a  collection  of 
modules.  Two  of  the  modules,  the  FUe  Policy  Manager  and  the  Dialoguer  are  trusted  processes. 
The  other  modules  are  instances  of  the  Kemd  Interface  Subsystem  (KISS). 

The  Dialoguer  is  a  process  to  which  the  user  terminal  can  be  reliably  connected.  This  connec¬ 
tion  occurs  whenever  the  user  types  a  predefined  break  sequence.  Now  the  user  and  system  can 
perform  reliable  authentication  and  modification  of  data  security  levels. 

The  File  Policy  Manager  implements  a  shared  file  system  while  maintaining  the  security  policy. 
All  requests  to  the  file  system  are  sent  to  the  kernel  which  then  forwards  them  to  the  Policy  Manager 
and  passes  its  response  back.  Since  the  kernel  manages  all  hardware  access  and  thus  defines  memory 
as  a  collection  of  virtual  memory  pages,  the  Policy  Manager  implements  the  file  system  using  these 
memory  pages. 

The  KISS  is  a  general  interface  to  the  kernel.  It  creates  a  more  usaUe  interface  between  general 
processes  and  the  kemeL  These  processes  do  not  directly  communicate  with  the  kernel  at  all.  Each 
KISS  is  a  separate  inteiface  for  one  process  such  as  the  scheduler,  network  interface  nucleus  or  a 
Unix  interface  emulator.  Each  of  these  higher  processes  can  then  be  interfaces  to  other  processes 
running  in  the  hardware  user  mode  such  as  Unix  user  processes,  or  the  Network  Manager. 

The  security  policy  implemented  by  this  kernel  and  the  trusted  processes  is  a  capability  based 
policy.  AH  operations,  whether  memory  or  I/O  related  are  governed  by  a  central  capability  mecha¬ 
nism.  Since  I/O  in  the  PDP-11  family  is  actually  memory  based  and  Unix  devices  are  special  files, 
aU  operations  must  go  through  the  Policy  Manager.  Success  of  all  operations  revolve  on  whether 
the  process  has  been  granted  the  capabOity  for  that  operation  on  ^t  object.  The  granting  of 
capabilities  is  actually  handled  only  in  the  File  Policy  Manager  and  not  in  the  kernel. 

This  system  is  a  fully  functional,  verified  operating  system  [Kem79].  Although  the  security 
policy  is  actually  implemented  outside  the  kernel  it  seems  to  maintain  a  fine  grain  protection 

*T)ic  etcslioa  of  the  Tirtsal  diicctoxics  k  »  good  of  a  kick 
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without  loss  of  integrity  or  much  performance  degradation.  Since  the  Policy  Manager  is  the  only 
process  with  the  ability  to  Grant  capabilities  this  system  may  prevent  some  operations  that  would 
be  valid  in  the  TCSEC  specification.  This  limitation  was  left  in  place  to  simplify  the  proof  and 
remove  several  problems  found  in  other  capability  based  systems. 

Secure  Distributed  Operating  Systems  The  following  systems  are  examples  of  Secure  Dis¬ 
tributed  operating  Systems.  They  help  enumerate  the  issues  involved  in  this  type  of  system: 

•  Security:  Again  security  is  a  primary  issue  and  the  reason  these  systems  exist.  They  are 
designed  to  provide  a  lot  of  functionality  while  still  maintaining  the  security  policy.  Here 
an  important  issue  is  the  model  used  for  the  system.  Both  of  these  systems  suppose  that 
a  constituent  operating  system  is  executing  on  each  host.  THETA  assumes  that  each  host 
system  has  been  verified  as  a  multilevel  system  for  that  single  host.  The  other  system  assumes 
the  host  systems  are  untmsted  and  thus  each  host  is  classified  at  a  single  security  level. 
Assuming  this  they  then  develop  different  methods  to  connect  the  individual  hosts  together. 

•  Integrity:  These  systems  let  the  constituent  operating  system  worry  about  data  integrity. 
Both  ensure  that  data  integrity  during  communication  between  hosts  is  maintained  although 
THETA  assumes  the  network  is  already  in  place  that  can  do  this. 

•  Resource  Management:  These  systems  both  let  the  constituent  operating  system  on  each  host 
actually  control  the  resources.  They  then  provide  services  to  client  processes  to  connect  them 
to  the  resources. 

•  Support:  These  systems  support  the  constituent  operating  system  on  their  host  and  then  the 
standardized  protocol  between  hosts.  Each  system  allows  processes  to  execute  on  the  host 
that  do  not  communicate  with  the  system  in  any  way. 

•  Performance:  Performance  is  an  issue  that  must  be  addressed,  although  in  these  systems  the 
tendency  is  to  assume  that  the  constituent  operating  system  on  each  host  will  be  able  to 
manage  the  additional  load  with  little  performance  penalties. 

Distributed  Secure  System  A  cost  effective  and  highly  efficient  system  has  been  proposed 
by  Rushby  and  Randell  [RR83].  This  system  is  composed  of  a  network  of  standard  UNIX  systems 
connected  thorough  the  "Newcastle  Connection”  and  small  trusted  hardware  devices. 

The  system  is  effectively  a  distributed  multilevel  system  which  acts,  from  the  users  vantage 
point,  as  a  multilevel  single  host  system.  The  main  technique  used  in  this  system  is  that  each  host 
actually  runs  as  a  singlelevel  system,  thus  implicitly  maintaining  the  mandatory  access  controls. 

The  individual  hosts  are  connected  by  a  system  called  "UNIX  UNITED”  [BMR82]  through  a 
local  area  network.  Between  each  host  system  and  the  is  the  heart  of  this  system  the  "Trustworthy 
Network  Interface  Unit”  (TNIU).  The  TNIU  unit  is  a  hardware  system  that  guarantees  via  label 
checking  and  encryption  that  messages  sent  across  the  network  maintain  the  mandatory  access 
policies.  In  other  words,  a  machine  classified  as  Tbp-Secret  can  not  send  any  messages  to  a  machine 
with  a  lower  security  clearance  such  as  Secret. 

This  system  supports  single  level  hosts  and  connects  them  together  to  develop  a  distributed 
multilevel  system.  It  supports  whatever  constituent  operating  systems  exist  on  the  hosts.  The 
distributed  nature  of  the  system  is  limited  by  the  inter-host  communication  protocol  established 
by  the  TNIU. 
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The  TNIU  it  a  very  good  idea  in  that  it  develops  a  tecnre  network  interface  and  network 
communication  by  encrypting  the  messages  in  the  hardware  before  sending  them  out.  Our  proposed 
kernel  will  use  this  idea  (slightly  modified)  to  establish  a  trusted  communication  path  between 
separate  hosts. 

Trusted  HETergeneous  Architecture  (THETA  -  was  SDOS)  The  THETA  system  is 
an  experimental  prototype  for  a  B3  level  secure  distributed  operating  system  [VCH88,  TCVW*88j. 
The  system  is  designed  to  allow  connection  of  a  network  of  hosts  with  a  heterogeneous  hardware 
and  software  base. 

The  main  premise  behind  the  THETA  system  is  that  the  network  meets  the  requirements 
for  B3  levd  classification,  and  each  host  runs  a  secure  multilevel  constituent  operating  system 
(COS)  which  also  meets  the  requirements  for  B3  levd  classification.  Using  these  assumptions  and 
the  '‘hook'Up”  requirement  of  McCullough  [McCST]  THETA  combines  the  COSs  and  network  to 
provide  a  B3  level  distributed  operating  system. 

THETA  exists  on  the  host  machine  as  a  collection  of  programs  running  as  separate  processes 
on  the  host  COS.  Using  THETA,  a  client  process  can  either  execute  on  the  host  COS  or  as  a  client 
of  an  THETA  process.  Either  way,  all  of  the  local  operating  system  functions  are  performed  by 
the  COS.  But,  whenever  a  client  process  wants  access  to  an  THETA  object  or  operation  it  must 
go  through  the  THETA  object  manager  process.  The  COS  guarantees  that  the  local  objects  and 
operations  provided  by  the  THETA  processes  are  protected  from  use  by  any  non>THETA  processes. 

One  of  the  THETA  programs  executing  on  the  local  host  is  called  the  switch.  This  is  a 
multilevel  process  and  exists  on  each  host.  All  operation  invocations  must  be  processed  by  the 
local  twitch.  If  the  operation  involves  communication  with  a  remote  host  then  the  switch  handles 
the  necessary  network  communications  and  eventually  retunu  the  reply  to  the  invoking  system 
manager  to  pass  on  to  the  client. 

Since  THETA  runs  as  a  dient  on  the  host  COS  it  should  be  much  easier  to  port  the  programs 
to  new  architectures.  The  verification  of  each  port  may  be  fimited  to  some  machine/COS  specific 
code  with  a  large  portion  of  the  THETA  code  untouched.  This  means  that  the  verification  of 
the  new  THETA  system  should  be  much  easier  that  the  initial  verification  of  the  whole  system. 
Unfortunately  THETA  does  assume  the  existence  of  a  verified  single  host  COS  existing  on  every 
system. 

As  the  previous  system,  THETA  is  limited  to  the  security  level  of  the  COS.  Communication 
between  THETA  clients  and  objects  is  managed  by  THETA  but  is  restricted  by  the  abilities  of  the 
COS.  Although  THETA  appears  to  have  more  of  a  distributed  nature  and  includes  security  as  a 
primary  focus  it  is  a  fuller,  and  thus  more  limited  system  than  a  kernel  would  be.* 

9.3.2  Our  Kernel 

The  kemd  proposed  here  targeted  for  a  distributed  operating  system  that  win  meet  the  Al  das. 
sification  level  as  defined  by  the  TCSEC.  It  executes  as  a  separate  proceu  on  each  host  and 
communicates  through  a  trusted  network  to  the  kernels  on  other  hosts.  Each  of  these  kernels  can 
be  viewed  as  a  general  resource  manager,  such  that  a  client  process  executing  under  control  of 
the  kernel  uses  the  operations  provided  by  it  to  access  any  resources  needed.  The  manager  will 
control  access  to  ail  resources  and  guarantee  that  the  security  policy  is  maintained  during  these 

*A  ftUler  qratem  baa  almdy  made  aeacral  protocol  aad  doaisB  dedaosa  wkiek  fiait  the  loibility  of  tbc  apatca. 
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Mcewes.  To  develop  tills  secure  geaeral  resource  manager  as  implemented  by  the  kernel  we  must 
first  understand  the  general  classes  of  resources  which  this  manager  must  control. 

Resources 

•  Single-Process  N on-preemptive-.  This  resource  type  is  allocated  to  a  tingle  process  at  a  time 
such  that  it  has  exclusive  access  to  that  resource  until  it  deallocates  the  resource.  Examples 
of  this  type  of  resource  are  a  terminal,  printer,  and  outside  communications  port. 

•  Single-Process  Preemptive:  These  resources  are  also  allocated  to  a  tingle  process  at  a  time, 
but  the  process  may  temporarily  loose  control  of  the  resource  to  another  process.  Examples 
of  this  type  of  resource  are  a  CPU,  and  some  coprocessors. 

•  Multiple-Process  Nen-Preemptive.  These  resources  may  be  allocated  to  more  than  one  process 
at  a  time.  This  may  be  accomplished  by  partitioning  the  resource  into  multiple  single-process 
subresources  or  simply  sharing  the  same  resource.  The  processes  are  guaranteed  access  to 
the  resource  until  they  deallocate  it.  Examples  of  this  type  of  resource  are  long  term  storage 
devices,  message  passing  channels  (possibly  limited  to  two  processes),  and  virtual  memory. 

•  Multiple-Process  Preemptive.  These  resources  are  also  allocated  to  multiple  processes  at  a 
time.  The  difference  here  is  that  the  process  may  temporarily  loose  control  of  the  resource 
to  another  process.  An  example  of  this  type  of  resource  is  physical  BAM  in  a  page  swapping 
environment. 

Resource  Manager  Now  that  we  know  the  types  oi  resources  that  the  manager  must  control  we 
should  determine  what  the  resource  manager  actually  does.  According  to  the  TCSEC  specification, 
at  the  higher  levels  of  classification  the  mani^er  must  contain  only  security  relevant  operations. 
It  must  also  manage  the  security  policy  of  the  system  including  auditing  controls.  FoUowing  this 
definition  ai^She  description  of  the  resource  types  given  above  we  see  that  there  are  some  immediate 
considerations  that  the  resource  manager  must  address. 

1.  For  the  preemptive  resources  we  must  develop  a  scheduling  policy,  possibly  a  separate  policy 
for  each  resource.  For  example  the  physical  BAM  would  probably  be  controlled  by  a  scheduler 
to  minimize  page  swapping,  while  the  CPU  scheduler  would  probably  be  a  circular  scheduler 
with  possibly  multiple  priority  queues  to  ensurq  faimeu. 

2.  Security  of  resources  is  also  important.  Each  resource  must  be  classified  at  a  certain  security 
level  and  this  level  may  be  changed  during  the  lifetime  of  the  resource.  If  use  of  a  resource  may 
possibly  violate  the  security  policy  then  it  must  be  monitored  by  a  trusted  resource  server. 
This  is  obviously  a  security  policy  concern  and  thus  is  managed  by  the  resource  manager. 

3.  Duplicate  resources  should  also  be  considered  for  the  preemptive  resources.  There  may  be 
multiple  copies  of  a  resource  or  a  resource  may  be  partitioned  into  identical  subresources.  In 
either  of  these  cases  a  preempted  user  should  be  able  to  be  rescheduled  to  any  of  the  identical 
resources  with  no  difficulty  or  detectable  difference.  Although  this  appears  primarily  to  be  a 
performance  issue,  knowledge  and  contrd  of  individual  resources  may  be  a  source  of  covert 
channels  and  thus  should  be  handled  by  the  resource  manager. 

4.  The  resource  manager  must  handle  the  audit  mechanisms  as  specified  by  the  TCSEC. 
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Model  Gives  the  ebove  requirements  for  the  resource  mnseger  the  kernel  cnn  still  implement 
it  mnny  different  wnys.  Each  of  these  implementation  methods  is  just  n  different  model  of  the 
resource  manager  but  result  is  the  same  overall  functionality.  The  following  list  consists  of  the 
models  that  are  currently  being  considered. 

•  Separation  Kernel.  The  kernel  provides  a  basic  set  of  services  to  allow  the  development  of 
several  virtual  machines.  Each  machine  will  be  a  virtual  distributed  entity  that  is  allocated 
a  set  of  private  resources  (storage)  and  is  assigned  a  security  classification.  All  users  and 
processes  using  this  machine  will  be  cleared  for  the  same  classification  level  as  the  machine. 
A  Need'to-Know  pdicy  will  be  implemented  on  each  virtual  machine  with  a  mandatory  policy 
governing  communication  between  machines  and  to  peripherals. 

•  Foliep  Kernel  This  is  currently  a  separate  idea,  but  may  be  eventually  merged  into  the  above 
concept.  A  policy  kernel  provides  a  bade  set  of  services  that  permits  the  policy  manager  to 
develop  a  statically  defined  security  policy  for  the  system.  The  services  are  general  enough 
that  any  policy  can  be  implemented  using  them.  The  security  verification  of  the  policy  would 
then  be  made  easier  by  using  the  services  as  secure  high>level  operations. 

•  Capability  Kernel  Here  the  kernel  is  similar  to  the  UCLA  Security  Kernel.  It  provides  simple 
operations  that  allow  the  user  to  manipulate  capabilities.  Thus,  the  capability  to  read  or  write 
an  object  has  to  be  explicitly  granted  to  the  user  allowing  the  system  to  directly  control  the 
rights  given  to  a  particular  user. 

•  Access  Control  Kernel  Here  the  kernel  maintains  the  access  control  lists  for  aU  objects. 
Bequests  to  access  an  object  must  be  granted  by  the  kernel  Anyone  with  the  appropriate 
privileges  in  the  access  control  lists  may  modify  the  access  rights  to  an  object.  Here  we  control 
the  distribution  of  data  by  guarding  these  access  privileges. 

Basic  Assumptions  Regardless  of  the  model  used,  the  development  of  the  kernel  as  a 
resource  manager  will  incorporate  the  following  assumptions: 

1.  Trusted  Userr.  It  is  assumed  that  the  users  of  the  system  are  trustworthy  up  to  the  level  of 
clearance  they  have  obtained.  These  users  will  not  deliberately  violate  security  properties  at 
this  level. 

2..  Trusted  Configuration:  It  is  assumed  that  thd  configuration  information,  security  classification 
of  devices  and  users,  is  accurate.  The  system  will  guarantee  that  only  a  trusted  security  officer 
will  be  able  to  modify  the  configuration  information. 

3.  Trusted  Identtfieotiom  It  is  assumed  that  there  exists  some  trusted  method  of  verifying  the 
identity  of  the  user  at  login  time. 

4.  Network  Seevrity:  It  is  assumed  that  the  communication  network  is  Secure  from  an  active 
wireUpper.  Rushby  and  Randell  [RR83]  developed  a  Trusted  Network  Interface  Unit  (TNIU) 
to  insure  secure  network  communication.  A  »iTnn«.r  hardware  device,  with  sHgbt  spedfica- 
tioa  changes  could  be  used  here.  The  communication  will  probably  based  on  public  key 
encryption  to  pemait  a  known  host  to  come  on-line  and  be  anthenticated. 
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5.  Physical  Security.  It  is  assumed  that  the  physical  security  of  devices  is  guaranteed.  Terminals, 
processors,  servers  and  various  peripherals  are  physically  located  in  areas  whose  security  level 
is  that  of  the  levels  of  the  devices,  (ie.,  an  outside  modem  line  could  not  be  considered  anything 
but  Unclassified  while  terminals  in  the  Pentagon  Security  Room  may  be  Top  Secret).  These 
devices  must  also  have  been  cleared  to  their  clearance  level. 

6.  Hardware  Integrity.  The  hardware  used  is  guaranteed  to  operate  according  to  its  specifica¬ 
tions. 

7.  Processor  Support:  The  processors  used  must  be  able  to  support  virtual  memory  capabilities, 
and  separation  of  memory  addresses.  We  do  not  want  an  untmsted  user  program  to  gain 
access  to  any  resources  not  allocated  to  it  by  the  security  kernel. 

Kernel  Services  In  this  section  I  define  the  basic  services  provided  by  the  kernel  that  are 
available  to  the  general  user.  Since  the  distributed  nature  of  the  kernel  is  transparent  to  the  user, 
the  distributed  environment  services  are  not  available  to  the  general  nser. 

The  following  is  a  list  of  possible  services  that  the  kernel  should  provide.  The  kernel  m^tains 
strict  control  over  the  physical  parameters  of  the  system.  Although  this  is  not  necessarily  a  complete 
list,  it  is  pretty  comprehensive.  Some  additional  services  may  be  added  if  the  kernel  model  is  an 
Capability  or  Access-Rights  kernel  to  manage  these  additional  resources. 

•  Resource  Allocation:  Exactly  how  this  is  performed  and  what  the  allocation  actually  means 
depends  on  the  type  of  resource.  For  example  the  kernel  will  allow  users  to  allocate  and 
deallocate  blocks  of  memory.  All  references  to  this  memory  will  be  relative  to  the  user’s 
memory  space.  Also  under  consideration  is  the  idea  of  allowing  the  user  to  define  memory 
segments,  each  of  which  will  be  a  separate  virtual  entity  with  associated  privileges.  This 
would  allow  for  the  creation  of  virtual  machines  in  which  user  processes  will  be  confined. 

•  Resource  Read  and  Write:  These  services  allow  the  user  to  communicate  with  any  resotirce 
allocated  to  the  user. 

•  Process  Control.  The  kernel  will  allow  users  to  create,  and  destroy  processes.  Currently  the 
kernel  will  manage  process  scheduling,  but  the  scheduling  of  user  processes  may  later  be 
relegated  to  a  specific  (possibly  unverified)  user  supplied  system  process.  If  so,  the  security 
of  the  interface  will  have  to  be  verified. 

•  I/O  Control  The  kernel  will  provide  services  to  handle  I/O  to  peripheral  devices.  There 
will  probably  be  two  methods  of  handling  I/O.  The  first  will  be  a  set  of  'trusted”  device 
drivers  that  are  accessed  through  specific  calls  and  interrupts.  The  kernel  will  ensure  that 
the  privileges  assigned  to  the  devices  are  not  exceeded  by  the  data  sent  to  the  driver.  The 
second  method  would  be  to  allow  a  user  to  exclusively  control  a  device  -  this  method  is  still 
under  consideration. 

•  Communication  Control  The  kernel  will  provide  services  that  will  carefully  monitor  all  inter¬ 
process  and  inter-machine  communications.  The  exact  mechanism  and  policy  for  this  is  still 
under  consideration.  The  final  services  will  maintain  the  security  policy  but  may  be  more 
restrictive.  This  communication  will  consist  of  intra-system  communication  between  processes 
in  the  same  distributed  system  and  inter-system  communication  between  processes  in  different 
distributed  systenu. 
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9.S.S  Summary 

Kernel  The  kernel  will  execute  as  an  independent  process  on  each  host.  It  will  have  complete 
control  of  the  hardware  and  system  resources.  When  connected  to  a  secure  network*  the  kernel 
will  communicate  with  other  identical  kernels  such  that  it  will  be  able  to  access  the  resources  the 
other  kernel  manages. 

This  kernel  will  provide  the  basic  functionality  expected  of  an  operating  system.  This  will 
include  process  creation,  deletion  and  scheduling  along  with  resource  management.  The  kernel  will 
implement  a  resource  manager  by  providing  services  to  client  processes  that  will  permit  them  to 
gain  access  to  the  resources  and  use  them. 

The  kernel  will  maintain  the  security  policy  of  the  system.  In  the  most  likely  implementation, 
objects  and  subjects  will  be  classified  with  respect  to  a  particular  security  compartment.  Within 
a  compartment,  the  rights  for  a  subject  to  access  an  object  will  be  explicitly  specified.  No  subject 
outside  the  compartment  will  have  rights  to  the  object. 

The  primary  research  issues  involved  here  are  summarised  below: 

•  Security:  This  issue  is  by  far  the  most  important  one  here  since  this  is  why  the  system  is 
being  designed.  Here  I  will  assume  that  if  each  kernel  on  an  individual  host  can  maintain 
the  security  policy,  if  the  kernels  communicate  using  a  standard  trusted  protocol  and  the 
communications  network  is  secure,  then  we  can  ensure  that  the  security  policy  is  maintained 
over  the  whole  system.  This  concept  has  been  formalized  by  McCullough  [McC87]  and  is 
used  in  the  THETA  system. 

•  Integrity:  Data  integrity  is  an  essential  part  of  computer  security  and  thus  is  also  a  key  issue 
in  this  system.  I  intend  to  design  the  system  to  guarantee  changes  in  data  are  authorized  and 
loss  of  data  due  to  node  failure  is  minimal. 

•  Resource  Management:  As  seen  earlier,  the  kernel  is  effectively  an  implementation  of  a  general 
resource  manager.  The  kernel  will  have  complete  control  of  the  resources  and  provide  services 
to  the  client  processes  for  use  of  these  resources. 

•  Support:  This  general  services  provided  by  this  kernel  can  be  used  by  client  processes  to  de¬ 
velop  an  execution  environment  that  is  compatible  with  popular  environments  that  currently 
exist  (ie.,  UNIX). 

% 

•  Performance:  Although  performance  is  an  important  issue,  this  system  will  sacrifice  perfor¬ 
mance  to  ensure  the  security  policy  if  no  more  efficient  method  is  available. 

Specification  and  Verification  The  det^  of  the  S3rstcm  will  be  specified  by  defining  the 
objects  of  the  system  and  the  operations  performed  mi  those  objects.  These  objects  wili  include 
system  specific  objects  that  are  not  available  to  cheat  processes.  The  specification  will  include  all  the 
information  necessary  to  implement  the  TCSEC  security  policy  but  not  restrict  the  implementation 
to  a  particular  method. 

The  verification  will  include  proof  that  specified  kemd  objects  maintain  certain  security  poli¬ 
cies.  These  policies  will  include  those  specified  by  the  TCSEC  [DOD83]  and  probably  the  "hook¬ 
up”  properties  of  McCullough{McC87].  These  properties  ensure  that  secure  single  host  systems  are 
connected  correctly  to  form  a  secure  multi-host  system. 

*A  Mcwc  Batwotk  m  eoa^cMd  eac  wkich  gswaaUw  tkat  mMMfei  sic  ddivmd  ealy  to  ike  proper  koet  %ad 
tkat  active  wiietappcre  caa  aot  iaterfere  witk  or  aaderstaad  tke  BMMagee. 
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Beyond  this  verification  the  system  will  have  to  be  analyzed  to  determine  if  any  covert  channels 
exist.  If  any  are  found  that  can  not  be  removed,  the  bandwidth  of  the  channel?  must  be  determined 
and  possible  methods  to  reduce  the  bandwidth  will  be  presented. 

Overall,  a  system  as  large  and  complex  as  a  security  kernel  will  provide  '  cellent  test  bed 
for  the  specification  and  verification  of  secure  distributed  systems.  In  addition  t,)  research  results 
on  the  kernel  itself,  the  kernel  project  will  drive  our  methodology  and  tool  research. 


10  Conclusions 

The  goal  of  this  project  was  to  investigate  techniques  for  the  verification  of  the  secimty  of  distributed 
systems.  In  carrying  out  the  work,  we  surveyed  the  following: 

•  Techniques  for  the  specification  and  verification  of  concurrent  and  distributed  programs 

•  Existing  mechanized  theorem  provers,  mostly  to  evaluate  their  suitability  for  verifying  con¬ 
current  and  distributed  programs 

•  Work  towards  the  development  of  exemplary  secure  distributed  systems,  even  in  cases  where 
verification  was  not  a  design  goal 

An  outgrowth  ei  oar  work  was  a  design  of  an  environment  suitable  for  the  specification  and 
verification  of  secure  distributed  systems,  and  descriptions  of  several  distributed  architectures  that 
would  be  amenable  to  verification. 

Our  conclusions  consider  the  following: 

•  The  need  for  secure  distributed  systems 

•  A  security  model  appropriate  to  distributed  systems 

•  A  suitable  abstraction  of  a  system  design  that  is  verified  with  respect  to  the  security  model 
-  A 1  certification 

•  The  feasibility  of  carrying  the  verification  below  the  level  of  an  abstract  design,  moving 
towards  beyond>Al  certification 

•  Mechanizations  of  the  verification  process  using  extensions  of  current  theorem  provers. 

•  Exemplary  distributed  systems  that  could  serve  as  vehicles  for  an  initial  attempt  to  produce 
an  A1  (or  beyond)  distributed  system. 

•  Other  research  topics  in  support  of  secure  distributed  systems. 

Informally,  a  system  is  secure  if  the  information  it  stores  is  protected  against  release  or  modi¬ 
fication  by  unauthorized  users.  The  Multilevel  Security  Policy  (MLS)  as  described  in  the  Orange 
Book  [DOD83]  associates  security  levels  with  users  and  objects,  and  requires  that  a  user  gets  to 
see  the  contents  of  objects  at  his  or  lower  levels;  that  is  information  can  flow  to  higher  levels  but 
never  lower  levels.  A  more  abstract  model  of  security  that  avoids  the  need  to  consider  objects  has 
been  formulated  by  Goguen  and  Meseguer  [GM84](GM82],  Feiertag,  Levitt  and  Robinson  [FLR77], 
and  McCullough  (McC87].  In  these  models  the  information  a  user  observes  is  to  be  dependent  only 
on  the  actions  of  users  at  his  level  or  lower.  That  as,  the  actions  of  higher  level  users  cannot  be 
observed  by  lower  level  users.  This  is  the  requirement  of  a  MLS  system,  including  a  distributed 
system.  Generalizations  of  MLS  can  also  be  modeled  with  these  systems  through  the  use  of  event 
systems  whose  elements  are  input,  output  or  transitioa  events.  The  events  any  user  sees  can  be 
specified  as  a  function  of  his  «iew,  a  view  bring  his  security  level,  his  group,  what  objects  others 
have  granted  him  access  to,  etc. 

The  burden  of  security  falls  on  the  operating  system,  although  appropriate  hardware  support 
can  minimize  the  impact  of  security  features  on  system  performance,  ^e  LOCK  system  is  an 
example  of  a  system  with  extensive  hardware  support,  although  all  systems  have  some  hardware 
support,  e.g.,  a  memory  management  unit. 

In  simple  terms  an  operating  system  that  satisfies  the  MLS  policy  (or  other  policies)  must 
enforce  access  control:  processes  have  access  to  objects  in  accordance  with  the  security  policy.  In 
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addition,  the  operating  system  itself  must  not  be  a  channel  for  the  communication  of  information 
not  in  accordaince  with  the  security  policy.  Such  unwanted  information  flow  can  potentially  occur 
through  objects  managed  by  the  operating  system  and  to  which  more  than  one -users  have  access; 
the  term  covert  channel  is  often  used  in  referring  to  such  objects. 

There  have  been  attempts  to  develop  systems  that  implement  the  MLS  policy,  most  for  single 
host /multiple  user  systems  such  as  mainframes  or  shared  workstations. 

In  recent  years  there  has  been  increasing  interest  in  distributed  systems  and,  naturally,  in  secure 
distributed  systems.  For  our  purposes  in  this  report  a  distributed  system  consists  of  hosts  (which 
could  be  workstations,  mainframes,  personal  computers),  servers  (which  could  be  repositories  for 
objects  accessible  to  multiple  hosts,  such  as  files,  directories,  names,  passwords,  etc.),  and  a  network 
through  which  the  hosts  and  servers  communicate  with  each  other.  Security  is  perhaps  more 
important  for  distributed  systems  in  that  such  systems  are  likely  to  have  many  hosts  and  many 
users  with  different  authotixations.  The  security  policy  for  a  distributed  system  is  identical  to  the 
(abstract)  version  of  MLS:  A  user  is  not  to  observe  the  actions  of  users  except  those  at  its  level  or 
lower.  A  user  can  be  associated  with  a  host  or  might  be  an  eavesdropper  on  the  network  -  passive 
or  active. 

There  have  been  several  proposals  for  secure  distributed  systems,  and  they  vary  according  the 
services  offered  by  the  system.  In  the  simplest  case,  each  host  can  support  a  single  user  or,  slightly 
more  generally,  users  operating  at  the  same  level.  In  this  case,  Rushby  and  Randell  [RR83],  the 
burden  of  assuring  security  falls  on  the  network,  which  can  mediate  all  communication  between 
hosts  to  assure  only  those  intended  to  communicate  with  each  other  do  so.  Indeed,  the  fact  that  the 
users  are  permitted  to  communicate  only  through  a  few  well  defined  interfaces  makes  the  attainment 
of  security  for  this  simple  (albeit  useful)  distributed  distributed  system  easier  than  for  a  multiuser 
mainframe.  More  complex  distributed  systems  would  include  multilevel  file  servers,  as  proposed  by 
Rushby  and  Randell. 

A  more  general  distributed  system  would  support  multilevel  hosts.  More  complex  distributed 
systems  permit  the  sharing  of  memory  or  of  hosts  across  the  system;  hosts  could  be  shared  through 
process  migration.  For  such  systems  the  attainment  of  security  requires  secure  hosts  in  addition  to 
secure  interhost  services. 

The  Orange  Book  defines  a  rating  for  a  secure  system  according  to  the  system's  services  in 
support  of  security  and  the  extent  of  the  certification  of  the  system  with  respect  to  a  security  policy. 
The  highest  ratings,  A1  and  beyond- Al,  are  granted  to  systems  that  have  been  formally  verified  to 
satisfied  the  pohcy.  Al  certification  requires  that  the  system  design  be  verified,  while  beyond-Al  is 
more  stringent  in  that  it  requires  the  verification  of  the  system’s  implementation.  For  a  single-host 
system  the  design  is  considered  to  be  the  specification  of  the  functional  behavior  of  each  service 
provided  by  the  system,  e.g.,  system  calls  and  ordinary  instructions  accessible  to  user  processes. 
A  few  systems  have  been  verified  according  to  the  Al  criterion.  We  are  aware  of  no  distributed 
systems  that  have  been  certified  to  be  Al.  A  goal  of  this  work  was  to  make  progress  towards  an 
Al  distributed  system,  through  the  definition  of  an  interface  for  a  secure  distributed  system  and  a 
specification  of  a  design. 

Once  the  interface  specification  of  a  system  has  been  verified,  it  remains  to  verify  the  imple¬ 
mentation.  Of  course,  a  system  cannot  be  considered  to  be  verified  unless  the  executable  code 
is  verified.  However,  many  errors  that  could  render  a  system  insecure  can  be  eliminated  through 
verification  of  design  decisions  that  can  be  formulated  in  stages  of  development  well  before  code 
is  produced.  One  approach  to  staging  the  development  and  verification  of  a  distributed  system 
is  to  consider  it  to  be  the  interconnection  of  large  self-contained  components,  each  of  which  has 
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a  tpadfication.  McCullough  has  developed  a  methodology  for  the  veriiication  of  systems  at  this 
level,  which  he  calls  hookup  veriiication;  the  security  policy  is  called  restrictiveness.  Through  the 
methodology  the  hookup  of  a  set  of  components  is  concluded  to  be  secure  provided  each  of  the 
components  (represented  by  its  spediication)  is  verified  to  satisfy  restrictiveness  and  their  hookup 
is  shown  to  satisfy  particular  properties, 

Our  work  extends,  mechanizes,  and  applies  the  McCullough  methodology.  Our  extension 
involves  writing  specifications  for  a  class  of  generic  building  blocks,  the  class  including  filters  of 
various  kinds.  Next  we  define  a  large  class  of  components  that  are  instantiations  of  these  filters  and 
show  that  the  instantiations  satisfy  restrictiveness.  These  components  include  queues,  transformers, 
multiplexors,  de>multiplexors,  and  switches.  A  secure  distributed  system  can  be  configured  using 
these  components  as  building  blocks,  these  blocks  providing  the  links  through  which  nntrusted 
components  communicate.  To  demonstrate  the  utility  of  the  methodology,  we  show  how  a  set  of 
our  components  can  be  connected  to  produce  a  verified  B.uahby>Banddl  distributed  system  design. 

All  proofs  are  mechanically  chewed  using  the  Higher  Order  Logic  (HOL)  system  developed 
at  Cambridge  [Gor88].  Of  the  existing  mechanical  proof  systems,  we  found  HOL  to  be  the  best 
suited  to  reasoning  about  the  interconnection  of  components  with  respect  to  a  security  policy.  HOL 
was  selected  for  this  project  based  on  its  support  for  higher  order  logic,  generic  specifications,  and 
polymorphic  type  constructs  -  all  in  support  of  writing  and  reasoning  about  general  classes  of 
components. 

Once  the  interconnection  of  a  system  of  high-level  building  blocks  has  been  established  to  satisfy 
the  security  policy,  it  remains  to  verify  the  implementation  of  the  blocks.  We  found  it  convenient 
to  divide  the  implementation  of  the  basic  building  blocks  into  two  basic  abstractions:  (1)  the  low 
level  mechanisms  that  provide  the  abstraction  of  processes,  especially  process  separation,  and  (2) 
secure  applications  that  involve  the  interaction  of  processes.  The  first  abstraction  is  successfully 
achieved  through  conventional  secure  operating  system  design  and  verification. 

The  second  is  best  achieved  through  programming  with  a  concurrent  programming  language, 
and  consequently  requires  reasoning  about  concurrent  programs.  Our  approach  to  the  verification 
of  concurrent  programs  involves  reasoning  about  the  specifications  of  interacting  programs  and 
then  verifying  the  specifications.  For  the  former,  we  favor  algebraic  specifications  in  the  style  of 
OBJ,  but  reflecting  the  concurrent  activity.  We  have  developed  an  extension  to  OBJ  (called  OBJC) 
which  uses  rewrite  rules  to  represent  concurrent  programs  that  share  state.  Security  properties, 
among  others,  can  be  expressed  in  OBJC  and  the  OBJ  rewrite  rules  can  be  shown  to  satisfy  such 
properties.  Although  any  theorem  prover  could  be  used,  we  have  found  it  convenient  to  build  the 
theories  necessary  to  accomplish  proofs  using  OBJ. 

To  carry  the  proof  down  to  the  level  of  executable  code,  we  suggest  using  a  concurrent  pro¬ 
gramming  language  that  runs  on  the  process  separation  kernel;  although  we  have  yet  to  establish 
the  formal  connection,  the  kernel  can  be  the  runtime  system  for  the  concurrent  programming  lan¬ 
guage.  We  suggest  using  the  language  SK  (Synchronizing  Eesonrces)  for  the  programming  of  secure 
applications.  Towards  demonstrating  the  utility  of  SR  we  have  developed  its  axiomatic  semantics 
and  showed  how  it  could  be  used  to  verify  specifications  of  concurrent  programs  expressed  in  the 
algebraic  style  of  OBJ. 

The  main  focus  of  the  project  was  on  the  verification  of  secure  distributed  s]rstems.  However, 
we  also  considered  two  aspects  of  secure  system  development  that  are  important  in  the  general 
context  of  software  engineering.  These  are  the  testing  of  secure  systems  and  the  rapid  prototyping 
of  such  systems. 

Regarding  testing,  we  have  developed  a  planning  system  for  the  intelligent  testing  of  secure 
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software.  The  syttem,  called  TPlan,  is  bwed  on  the  ideas  of  STRIPS  and  GPS.  A  goal  is  presented 
to  TPlan  that  represents  a  particular  state  one  hopes  the  program  under  test  will  not  enter;  with 
respect  to  security,  the  state  is  one  where  an  user  has  unauthorized  access  to  objects  or  where 
information  has  leaked  through  covert  channels.  TPlan  can  do  an  exhaustive  search,  but  can  take 
advantage  of  heuristics  such  as:  particular  operations  that  might  represent  flaws  in  the  system 
and  how  many  processes  should  be  involved  in  exposing  the  flaw  (each  process  requiring  a  context 
switch  to  become  active).  TPlan  produces  a  plan  which  can  be  interpreted  as  a  test  sequence  that 
exposes  a  flaw. 

Regarding  rapid  prototyping,  we  have  noted  that  many  operating  systems  share  structure.  We 
have  developed  a  template  for  the  rapid  prototyping  of  operating  systems,  the  template  consisting 
of  4  levels  of  spedflcation  in  an  executable  specification  language.  Using  the  template,  a  designer 
can  propose  policies  for  access  control,  process  switching,  scheduling,  memory  and  file  management 
in  terms  of  rules  that  are  interpreted  as  programs.  Currently,  we  are  using  our  template  to  pro¬ 
duce  a  rapid  prototype  of  the  MINDC  operating  system.  The  implementation  of  MINIX  r^uires 
12.000  lines  of  C  and  assembly  code;  our  rapid  prototype  will  require  approximately  1000  lines  of 
specification. 
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